Computer, vehicle, server, mobile terminal, and vehicle management method

Abstract

The present disclosure relates to a computer, a vehicle, a server, a mobile terminal, and a vehicle management method. The computer is provided with a diagnosis section that, for a vehicle in which an abnormality has occurred and that is unable to continue travel by automatic driving, judges whether the vehicle can be repaired on the spot and whether the vehicle can travel by manual driving. Such a computer can be mounted on any one of a vehicle, a server, and a mobile terminal.

Description

Technical Field

[0001] This disclosure relates to computers, vehicles, servers, mobile terminals, and vehicle management methods. Background Technology

[0002] A vehicle system for scheduling autonomous vehicles is disclosed in Japanese Patent Application Publication No. 2020-074169.

[0003] It is foreseeable that, with advancements in autonomous driving technology, there will be an increase in the use of autonomous vehicles by users unfamiliar with driving (those lacking driving skills) or those unfamiliar with cars, operating them without a manager present. If such users encounter malfunctions while using autonomous vehicles and are unable to continue driving autonomously, they may be unable to handle the situation independently and will be helpless. Even if users can contact support centers via mobile phone, they may not be able to accurately describe the situation, wasting time before receiving assistance. Summary of the Invention

[0004] This disclosure was made to address the aforementioned problems, and its purpose is to provide a computer, vehicle, server, mobile terminal, and vehicle management method that can take early and appropriate action on a vehicle when an anomaly occurs during autonomous driving.

[0005] The computer of the first aspect disclosed herein includes: a diagnostic unit that determines whether a vehicle can be repaired on the spot and whether it can be driven manually if it malfunctions and is unable to continue driving via automatic driving; and a response processing unit that performs prescribed processing based on the judgment results obtained by the diagnostic unit.

[0006] The aforementioned computer automatically assesses the vehicle's condition. Then, based on the assessment result, it executes the prescribed procedures. Therefore, even if a vehicle driven by an unfamiliar driver (a user without driving skills) or a user unfamiliar with automobiles malfunctions, appropriate action can be taken promptly and effectively.

[0007] Alternatively, the response unit may be configured to arrange for a rescue vehicle to be moved to a rescue vehicle if the diagnostic unit determines that the vehicle cannot be repaired on the spot and cannot be driven manually. Alternatively, the response unit may be configured not to arrange for a rescue vehicle in either the case where the diagnostic unit determines that the vehicle can be repaired on the spot, or the case where the diagnostic unit determines that the vehicle can be driven manually.

[0008] The aforementioned computer automatically determines whether a tow truck is needed. Because tow truck dispatch is automated, it ensures timely and appropriate dispatch even in cases where a vehicle driven by an inexperienced driver or someone unfamiliar with the vehicle malfunctions. Furthermore, if it is determined that no tow truck is needed, dispatching one is not required, thereby mitigating the increased costs associated with unnecessary tow truck dispatches.

[0009] Alternatively, the response unit may be configured to, if the diagnostic unit determines that the vehicle can be repaired on the spot, display instructions indicating the repair process on at least one of the terminal mounted on the vehicle and the terminal of the user using the vehicle.

[0010] Based on the above configuration, users follow the instructions to proceed with the repair work, thus enabling them to complete the repair work easily and quickly. The terminal installed in the vehicle can be a car navigation system. The terminal used by the user of the vehicle can be a mobile terminal (e.g., a smartphone or wearable device).

[0011] In the aforementioned computer, the diagnostic unit may also be configured to: when the user inputs an indication of work termination into a terminal displaying instructions, withdraw the aforementioned judgment that the vehicle with the malfunction could be repaired on the spot, and determine that the vehicle with the malfunction cannot be repaired on the spot.

[0012] Based on the above configuration, it is easy to accurately determine whether anomalies occurring in autonomous vehicles can be repaired on the spot. Specifically, when a computer makes an incorrect judgment, the user's judgment can be prioritized, and the error can be corrected.

[0013] Alternatively, the diagnostic department may be configured to determine whether the handling method for the abnormality is obvious and whether the vehicle with the abnormality can be repaired within a specified time. Alternatively, the diagnostic department may be configured to determine that the vehicle with the abnormality can be repaired on the spot if the handling method for the abnormality is obvious and the vehicle with the abnormality can be repaired within a specified time.

[0014] Based on the above structure, it is easy to accurately determine whether an autonomous vehicle that has malfunctioned can be repaired on the spot.

[0015] In the aforementioned computer, the diagnostic unit may also be configured to use user information related to the user using the vehicle to determine whether the vehicle that has malfunctioned can be repaired within a specified time.

[0016] Based on the above structure, user information related to the user using the autonomous vehicle that has malfunctioned can be used to accurately determine whether the vehicle can be repaired within a specified time.

[0017] Alternatively, the diagnostic unit can be configured to determine whether the vehicle can be switched to manual driving and whether a person capable of manually driving the vehicle is riding in the vehicle. Alternatively, the diagnostic unit can be configured to determine that the vehicle can be driven manually if the vehicle can be switched to manual driving and a person capable of manually driving the vehicle is riding in the vehicle.

[0018] Based on the above configuration, it is easy to accurately determine whether an autonomous vehicle experiencing an anomaly can still be driven manually. If the anomaly does not impede manual driving, the diagnostic unit can determine that the vehicle can be switched to manual driving.

[0019] Alternatively, the diagnostic unit can be configured to use the output of sensors that detect the presence of a person in the vehicle and user information related to the user using the vehicle to determine whether a person capable of manually driving the vehicle is riding in the vehicle. With this configuration, it is easy to accurately determine whether a person capable of manually driving the vehicle is riding in the vehicle.

[0020] Alternatively, the response unit can be configured to perform driver assistance processing when a vehicle, unable to continue driving automatically due to an anomaly, can be driven manually. With this configuration, it is easy to appropriately manage the vehicle when driving manually. Driver assistance processing can include destination display or driver assistance via ADAS (Advanced Driving Assistance System).

[0021] The second aspect of this disclosure describes a vehicle equipped with a control device. The vehicle also includes: an autonomous driving suite; and a vehicle control interface that mediates the exchange of signals between the control device and the autonomous driving suite. The autonomous driving suite is configured to send instructions for autonomous driving to the control device via the vehicle control interface. The control device is configured to control the vehicle according to the instructions from the autonomous driving suite. The control device is configured to send signals indicating the vehicle's state to the autonomous driving suite via the vehicle control interface. Furthermore, the control device or the autonomous driving suite includes any of the aforementioned computers.

[0022] The aforementioned vehicle includes the aforementioned computer, thus enabling timely and appropriate action to be taken against the vehicle when an anomaly occurs during autonomous driving.

[0023] The server for the third viewpoint of this disclosure includes any of the aforementioned computers.

[0024] The aforementioned server includes the computer mentioned above, thus enabling timely and appropriate action to be taken against the vehicle when an anomaly occurs during autonomous driving.

[0025] The mobile terminal of the fourth aspect of this disclosure includes any of the aforementioned computers.

[0026] The aforementioned mobile terminal includes the aforementioned computer, thus enabling timely and appropriate action to be taken against the vehicle when an anomaly occurs during autonomous driving.

[0027] The vehicle management method of the fifth point of this disclosure includes the first judgment, the second judgment, the third judgment, and the arrangement of rescue vehicles as shown below.

[0028] In the first judgment, the computer determines whether the vehicle in autonomous driving mode has experienced an anomaly that prevents it from continuing to drive autonomously. In the second judgment, the computer determines whether the vehicle with the anomaly can be repaired on the spot. In the third judgment, the computer determines whether the vehicle with the anomaly can be driven manually. In the rescue vehicle dispatch, if the vehicle with the anomaly cannot be repaired on the spot and cannot be driven manually, the computer dispatches a rescue vehicle to move the vehicle to a rescue vehicle.

[0029] Similar to the aforementioned computer, the vehicle management method described above can also be used to take timely and appropriate action against a vehicle when an anomaly occurs during autonomous driving.

[0030] According to this disclosure, when an anomaly occurs in a vehicle operating in autonomous driving, appropriate measures can be taken against the vehicle as early as possible. Attached Figure Description

[0031] Hereinafter, with reference to the accompanying drawings, the features, advantages, and technical and industrial significance of exemplary embodiments of the present invention will be described, wherein the same reference numerals denote the same elements, wherein:

[0032] Figure 1 This is a diagram illustrating the schematic configuration of a vehicle according to an embodiment of the present disclosure.

[0033] Figure 2 It means Figure 1 A diagram showing details of the vehicle's control system.

[0034] Figure 3 This is a flowchart illustrating the processing procedure of automatic driving control according to an embodiment of the present disclosure.

[0035] Figure 4 It is used for Figure 1 The diagram illustrates the details of the control devices and various systems of the vehicle shown.

[0036] Figure 5 This is a flowchart illustrating a vehicle management method according to an embodiment of the present disclosure.

[0037] Figure 6 It means in Figure 5 The flowchart shown details the process for repairing vehicles that have experienced abnormalities in the vehicle management method.

[0038] Figure 7 It means in Figure 6 The flowchart shows the details of the on-site repair response (repair response without vehicle movement) during the repair process.

[0039] Figure 8 It means in Figure 6 The flowchart shown details the repair procedures involving vehicle movement.

[0040] Figure 9 It means Figure 5 The flowchart of the first variation of the process shown.

[0041] Figure 10 It means Figure 5 The flowchart of the second variation of the process is shown. Detailed Implementation

[0042] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. It should be noted that in the drawings, the same or corresponding parts are labeled with the same reference numerals, and their descriptions will not be repeated.

[0043] Figure 1 This is a diagram illustrating a schematic configuration of a vehicle according to an embodiment of the present disclosure. (See also...) Figure 1 Vehicle 1 is equipped with an autonomous driving kit (hereinafter referred to as "ADK" 200) and a vehicle platform (hereinafter referred to as "VP" 2).

[0044] VP2 includes the control system of the base vehicle 100 and a vehicle control interface box (hereinafter referred to as "VCIB"). VCIB 111 is located within the base vehicle 100. VCIB 111 can communicate with ADK200 via an in-vehicle network such as CAN (Controller Area Network). It should be noted that... Figure 1 In the diagram, the base vehicle 100 and ADK200 are shown in separate positions, but ADK200 is actually mounted on the base vehicle 100. In this embodiment, ADK200 is mounted on the roof of the base vehicle 100. However, the mounting position of ADK200 can be appropriately changed.

[0045] The base vehicle 100 is, for example, a commercially available xEV (electric vehicle). An xEV is a vehicle that uses electricity as its power source, either entirely or partially. In this embodiment, a BEV (Battery Electric Vehicle) is used as the base vehicle 100. However, it is not limited to this; the base vehicle 100 can also be an xEV other than a BEV (HEV (Hybrid Electric Vehicle), PHEV (Plug-in Hybrid Electric Vehicle), FCEV (Fuel Cell Electric Vehicle), etc.). The base vehicle 100 has, for example, four wheels. However, it is not limited to this; the base vehicle 100 can have three or more wheels.

[0046] In addition to the integrated control manager 115, the control system of the base vehicle 100 includes various systems and sensors for controlling the base vehicle 100. The integrated control manager 115 comprehensively 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.

[0047] In this embodiment, the integrated control manager 115 includes a control device 150. The control device 150 includes a processor 151, RAM (Random Access Memory) 152, and a storage device 153. The processor 151 may be, for example, a CPU (Central Processing Unit). The RAM 152 functions as working memory, temporarily storing data processed by the processor 151. The storage device 153 is configured to store stored information. The storage device 153 may include, for example, ROM (Read Only Memory) and rewritable non-volatile memory. In addition to the program, the storage device 153 stores information used in the program (e.g., maps, formulas, and various parameters). In this embodiment, the processor 151 executes the program stored in the storage device 153, thereby performing various vehicle controls (e.g., automatic driving control according to instructions from ADK200). However, these processes may also be performed by dedicated hardware (electronic circuitry) instead of software. It should be noted that the number of processors in the control device 150 is arbitrary, and processors can be prepared for each specified control.

[0048] The base vehicle 100 includes a braking system 121, a steering system 122, a powertrain system 123, an active safety system 125, and a body system 126. These systems are controlled by a unified control manager 115. In this embodiment, each system has a computer. Furthermore, the computer of each system communicates with the unified control manager 115 via an in-vehicle network (e.g., CAN). Hereinafter, the computer of each system will be referred to as an "ECU (Electronic Control Unit)".

[0049] The braking system 121 includes braking devices for each wheel of the base vehicle 100 and an ECU for controlling the braking devices. In this embodiment, a hydraulic disc brake is used as the braking device. The base vehicle 100 is equipped with wheel speed sensors 127A and 127B. Wheel speed sensor 127A is located on the front wheels of the base vehicle 100 and detects the rotational speed of the front wheels. Wheel speed sensor 127B is located on the rear wheels of the base vehicle 100 and detects the rotational speed of the rear wheels. The ECU of the braking system 121 outputs the rotational direction and rotational speed of each wheel detected by the wheel speed sensors 127A and 127B to the integrated control manager 115.

[0050] The steering system 122 includes a steering mechanism of the base vehicle 100 and an ECU that controls the steering mechanism. The steering mechanism may include, for example, a rack and pinion type EPS (Electric Power Steering) that allows adjustment of the steering angle via 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 the pinion gear connected to the rotation shaft of the actuator constituting the steering mechanism. The ECU of the steering system 122 outputs the pinion angle detected by the pinion angle sensor 128 to the integrated control manager 115.

[0051] The powertrain 123 includes: an EPB (Electric Parking Brake) located on at least one of the wheels of the base vehicle 100; a P-Lock device located on the transmission of the base vehicle 100; a shift mechanism configured to select a gear; a drive source for the base vehicle 100; and an ECU that controls the devices included in the powertrain 123. The EPB is separate from the aforementioned braking device and uses an electric actuator to fix the wheels. The P-Lock device, for example, uses a parking lock pawl that can be driven by an actuator to fix the rotational position of the transmission output shaft. Details will be described later, but in this embodiment, a motor powered by a battery is used as the drive source for the base vehicle 100. The ECU of the powertrain 123 controls the presence or absence of fixing by the EPB and P-Lock device, the gear selected by the shift mechanism, and the battery and motor (see later description). Figure 4 Each status is output to the integrated control manager 115.

[0052] The active safety system 125 includes an ECU that determines the likelihood of a collision with the vehicle 1 while it is in motion. The base vehicle 100 is equipped with a camera 129A and radar sensors 129B and 129C that detect the surrounding conditions, including those in front of and behind the vehicle 1. The ECU of the active safety system 125 uses signals received from the camera 129A and radar sensors 129B and 129C to determine whether a collision is possible. If the active safety system 125 determines that a collision is possible, the integrated control manager 115 outputs a braking command to the braking system 121 to increase the braking force of the vehicle 1. The base vehicle 100 of this embodiment has the active safety system 125 from the outset (at the factory). However, it is not limited to this; an active safety system that can be retrofitted to the base vehicle may also be used.

[0053] The body system 126 includes body components (e.g., a turn indicator, a horn, and a wiper) and an ECU that controls the body components. In manual mode, the ECU of the body system 126 controls the body components according to user operation; in autonomous mode, it controls the body components according to instructions received from the ADK200 via the VCIB111 and the integrated control manager 115.

[0054] Vehicle 1 is configured for autonomous driving. VCIB111 functions as the vehicle control interface. When Vehicle 1 is driving autonomously, the integrated control manager 115 and ADK200 exchange signals via VCIB111. The integrated control manager 115 executes autonomous driving control (i.e., autonomous driving control) based on instructions from ADK200. It should be noted that ADK200 can also be removed from the base vehicle 100. Even with ADK200 removed, the base vehicle 100 can still be driven by a user as a standalone vehicle. When driving as a standalone vehicle, the control system of the base vehicle 100 executes manual driving control (i.e., driving control corresponding to user operation).

[0055] In this embodiment, ADK200 exchanges signals with VCIB111 according to the API (Application Program Interface) defined for each signal being communicated. ADK200 is configured to process various signals defined by the aforementioned API. For example, ADK200 creates a driving plan for vehicle 1 and outputs various commands requesting control to make vehicle 1 drive according to the created driving plan to VCIB111 according to the aforementioned API. Hereinafter, each of the aforementioned commands output from ADK200 to VCIB111 will also be referred to as an "API command". Furthermore, ADK200 receives various signals representing the state of the base vehicle 100 from VCIB111 according to the aforementioned API and reflects the received state of the base vehicle 100 in the creation of the driving plan. Hereinafter, each of the aforementioned signals received by ADK200 from VCIB111 will also be referred to as an "API signal". Both API commands and API signals are equivalent to signals defined by the aforementioned API. Details regarding the configuration of ADK200 will be described later (see [link to documentation]). Figure 2 ).

[0056] VCIB111 receives various API commands from ADK200. When VCIB111 receives an API command from ADK200, 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 the Integrated Control Manager 115 can process is also referred to as a "control command." When VCIB111 receives an API command from ADK200, it outputs the corresponding control command to the Integrated Control Manager 115.

[0057] The control unit 150 of the integrated control manager 115 sends various signals (e.g., 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 VCIB 111. VCIB 111 sequentially receives signals indicating the state of the base vehicle 100 from the integrated control manager 115. VCIB 111 determines the value of the API signal based on the signals received from the integrated control manager 115. Furthermore, VCIB 111 converts the signals received from the integrated control manager 115 into API signal form as needed. Then, 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 VCIB 111 to the ADK 200 in real time.

[0058] In this embodiment, signals with low universality, such as those defined by the automobile manufacturer, are exchanged between the integrated control manager 115 and VCIB 111, while signals with higher universality (e.g., signals defined by an open API) are exchanged between ADK 200 and VCIB 111. VCIB 111 performs signal conversion between ADK 200 and integrated control manager 115, thereby enabling integrated control manager 115 to control the vehicle according to instructions from ADK 200. However, the function of VCIB 111 is not limited to performing the aforementioned signal conversion. For example, VCIB 111 can also make predetermined judgments and send signals based on its judgment results (e.g., signals for notification, instruction, or request) to at least one of integrated control manager 115 and ADK 200. Details regarding the configuration of VCIB 111 will be described later (see [reference]). Figure 2 ).

[0059] The base vehicle 100 also includes a communication device 130. The communication device 130 includes various communication I / Fs (interfaces). The control device 150 is configured to communicate with external devices of the vehicle 1 (e.g., the mobile terminal UT and server 500 described later) via the communication device 130. The communication device 130 includes a wireless communication device (e.g., a DCM (Data Communication Module)) capable of accessing a mobile communication network (Telematics: vehicle-to-everything network). The communication device 130 communicates with the server 500 via the mobile communication network. The wireless communication device may include communication I / Fs compatible with 5G (fifth-generation mobile communication system). Furthermore, the communication device 130 includes communication I / Fs for direct communication with the mobile terminal UT located within or around the vehicle. The communication device 130 and the mobile terminal UT can perform short-range communication such as wireless LAN (Local Area Network), NFC (Near Field Communication), or Bluetooth (registered trademark).

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

[0061] The aforementioned vehicle 1 can be used as one of the components of a MaaS (Mobility as a Service) system. MaaS systems include, for example, MSPF (Mobility Service Platform). MSPF is a unified platform connecting various mobility services (e.g., various mobility services provided by ride-sharing operators, car-sharing operators, insurance companies, rental car operators, taxi operators, etc.). Server 500 is a computer that manages and exposes information for mobility services within MSPF. Server 500 manages various mobility information and provides information (e.g., APIs and information related to collaboration between mobility services) based on requests from operators. Operators providing services can utilize the various functionalities offered by MSPF using the APIs exposed on MSPF. For example, the APIs required for ADK development are exposed on MSPF.

[0062] Server 500 includes a processor 501, RAM 502, storage device 503, and HMI (Human Machine Interface) 504. Storage device 503 is configured to store information. In addition to programs, storage device 503 stores information used in the programs (e.g., mappings, formulas, and various parameters). HMI 504 includes input devices and display devices. HMI 504 may be a touch panel display. HMI 504 may also include a smart speaker that accepts voice input.

[0063] Figure 2 This is a diagram showing details of the control system of vehicle 1. (Refer to...) Figure 1 Simultaneously refer to Figure 2 ADK200 includes an autonomous driving system (hereinafter referred to as "ADS").202 for performing autonomous driving of vehicle 1. ADS202 includes a computer 210, an HMI (Human Machine Interface) 230, a recognition sensor 260, a posture sensor 270, and a sensor cleaner 290.

[0064] Computer 210 includes a processor and a storage device for autonomous driving software that uses APIs, and is configured to execute the autonomous driving software via the processor. The autonomous driving software performs controls related to autonomous driving (see below). Figure 3 The autonomous driving software can be updated sequentially via OTA (Over-The-Air). Computer 210 also includes communication modules 210A and 210B.

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

[0066] The identification sensor 260 includes various sensors that acquire information (hereinafter also referred to as "environmental information") for identifying the external environment of the vehicle 1. The identification 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 identification sensor 260 includes a camera that captures images of the surroundings of the vehicle 1 (including the front and rear) and an obstacle sensor (e.g., millimeter-wave radar and / or lidar) that senses obstacles via electromagnetic waves or sound waves. The computer 210 can, for example, use the environmental information received from the identification sensor 260 to identify people, objects (other vehicles, pillars, guardrails, etc.) and lines on the road (e.g., center lines) that are within a range that can be identified from the vehicle 1. Artificial intelligence (AI) or image processing processors can also be used for identification.

[0067] The attitude sensor 270 acquires information related to the attitude of vehicle 1 (hereinafter also referred to as "attitude information") and outputs it to computer 210. The attitude sensor 270 includes various sensors that detect the acceleration, angular velocity, and position of 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 of vehicle 1 in the longitudinal, lateral, and vertical directions, as well as the angular velocities of vehicle 1 in the roll, pitch, and yaw directions. The GPS sensor uses signals received from multiple GPS satellites to detect the position of vehicle 1. In the fields of automobiles and aircraft, techniques for combining IMUs with GPS to measure attitude with high accuracy are well known. Computer 210 can also use such well-known techniques, for example, to measure the attitude of vehicle 1 based on the aforementioned attitude information.

[0068] Sensor cleaner 290 is a device for removing dirt from sensors (e.g., identification sensor 260) exposed to outside air outside the vehicle. For example, sensor cleaner 290 can be configured to use cleaning fluid and a wiper to clean the lens of a camera and the outlet of an obstacle sensor.

[0069] In vehicle 1, redundancy is provided for prescribed functions (e.g., braking, steering, and vehicle fixation) to enhance safety. The control system 102 of the base vehicle 100 includes multiple systems performing equivalent functions. Specifically, the braking system 121 includes braking systems 121A and 121B. The steering system 122 includes steering systems 122A and 122B. The powertrain system 123 includes an EPB system 123A and a P-Lock system 123B. Each system has an ECU. In these multiple systems performing equivalent functions, even if one malfunctions, the others continue to operate normally, thus ensuring the proper functioning of that function in vehicle 1.

[0070] VCIB111 includes VCIB111A and VCIB111B. Each of VCIB111A and VCIB111B includes a computer. Communication modules 210A and 210B of computer 210 are configured to communicate with the computers of VCIB111A and VCIB111B, respectively. VCIB111A and VCIB111B are connected to communicate with each other. VCIB111A and VCIB111B can each operate independently; even if one malfunctions, the other will continue to operate normally, thus ensuring the normal operation of VCIB111. Both VCIB111A and VCIB111B are connected to the aforementioned systems via integrated control manager 115. However, as... Figure 2 As shown, the connection target portion differs in VCIB111A and VCIB111B.

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

[0072] Vehicle 1 is configured to switch between autonomous and manual modes. The API signals received by ADK200 from VCIB111 include a signal indicating whether Vehicle 1 is in autonomous or manual mode (hereinafter referred to as "autonomous mode"). The user can select either autonomous or manual mode via a designated input device (e.g., HMI230 or mobile terminal UT). When the user selects a driving mode, Vehicle 1 enters the selected driving mode, and the selection result is reflected in the autonomous mode. However, if Vehicle 1 is not in a state capable of automatic driving, it will not switch to autonomous mode even if the user selects it. Switching between driving modes of Vehicle 1 can be performed by the integrated control manager 115. The integrated control manager 115 can switch between autonomous and manual modes based on the status of Vehicle 1.

[0073] When vehicle 1 is in autonomous mode, computer 210 obtains the state of vehicle 1 from VP2 and sets the next action of vehicle 1 (e.g., acceleration, deceleration, and turning). Then, computer 210 outputs various instructions to implement the set next action of vehicle 1. Computer 210 executes API software (i.e., autonomous driving software using API), thereby sending instructions related to autonomous driving control from ADK200 to integrated control manager 115 via VCIB111.

[0074] Figure 3 This is a flowchart illustrating the processes performed by ADK200 in the autonomous driving control of this embodiment. When vehicle 1 is in autonomous mode, the processes shown in this flowchart are repeatedly executed according to the cycle corresponding to the API (API cycle). When the driving mode of vehicle 1 switches from manual mode to autonomous mode, after a start signal indicating the start of autonomous driving is sent from vehicle 1 (communication device 130) to server 500 along with vehicle 1's identification information, the following description begins. Figure 3 The flowchart illustrates a series of processes. Hereafter, each step in the flowchart will be simply labeled "S".

[0075] Reference Figure 1 and Figure 2 Simultaneously refer to Figure 3 In S101, computer 210 acquires current vehicle 1 information. For example, computer 210 acquires environmental and posture information of vehicle 1 from recognition sensor 260 and posture sensor 270. Furthermore, computer 210 acquires API signals. In this embodiment, whether vehicle 1 is in autonomous mode or manual mode, API signals representing the state of vehicle 1 are sequentially output from VCIB 111 to ADK 200 in real time. To improve the accuracy of autonomous driving control, the state of vehicle 1 can be sequentially sent from integrated control manager 115 to ADK 200 in autonomous mode at a shorter cycle than in manual mode. The API signals acquired by computer 210 include, in addition to the aforementioned autonomous state, signals representing the rotation direction and speed of each wheel detected by wheel speed sensors 127A and 127B.

[0076] In S102, computer 210 creates a driving plan based on the information about vehicle 1 obtained in S101. For example, computer 210 calculates the behavior of vehicle 1 (e.g., the posture of vehicle 1) and creates a driving plan suitable for the state of vehicle 1 and the external environment. The driving plan is data representing the behavior of vehicle 1 within a specified period. If a driving plan already exists, it can be modified in S102.

[0077] In S103, computer 210 extracts control physical quantities (acceleration, tire angle, etc.) from the driving plan created in S102. In S104, computer 210 divides the physical quantities extracted in S103 into API cycles. In S105, computer 210 uses the physical quantities divided in S104 to execute the API software. By executing the API software in this way, ADK200 sends API commands (propulsion direction command, propulsion command, braking command, vehicle fixation command, etc.) to VCIB111 to implement control according to the physical quantities of the driving plan. VCIB111 sends the control command corresponding to the received API command to the integrated control manager 115, which performs automatic driving control of vehicle 1 according to the control command.

[0078] In the next step, S106, computer 210 determines whether vehicle 1 is in autonomous mode. During the period when autonomous mode is active (yes in S106), the processes described in S101 to S105 are repeatedly executed, thereby performing automatic driving of vehicle 1. On the other hand, when vehicle 1 enters manual mode (no in S106), in S107, after a termination signal indicating the end of automatic driving is sent from vehicle 1 (communication device 130) to server 500 along with vehicle 1's identification information, ... Figure 3 The series of processes shown concludes. In this embodiment, computer 210, VCIB 111, and integrated control manager 115 cooperate to execute controls for enabling vehicle 1 to operate autonomously. Vehicle 1 can operate autonomously in either a manned or unmanned state. It should be noted that autonomous driving control is not limited to... Figure 3 The control shown can also be other controls (known automatic driving controls).

[0079] Figure 4 This diagram illustrates the details of the control device 150 and various systems provided in vehicle 1. (Refer to...) Figure 1 and Figure 2 Simultaneously refer to Figure 4 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, a pressure sensor 30b, a occupant sensor 40, a battery 160, a navigation system (hereinafter also referred to as "NAVI") 170, a reader 180, and drive wheels W. The MG 20, ECU 21, and PCU 22 are included in the propulsion system 123C. The braking device 30 and the brake sensor 30a are included in the braking system 121 (… Figure 1 )middle.

[0080] Battery 160 supplies power to propulsion system 123C. Battery 160 can be a known vehicle energy storage device (e.g., a liquid secondary battery, an all-solid-state secondary battery, or a battery pack). Examples of vehicle secondary batteries include lithium-ion batteries and nickel-metal hydride batteries. Battery 160 is configured to be charged via contact (plug-in charging).

[0081] A monitoring module 160a is provided in the battery 160. The monitoring module 160a includes various sensors that detect the state of the battery 160 (e.g., voltage, current, and temperature) and outputs the detection results to the integrated control manager 115. The monitoring module 160a may be a BMS (Battery Management System) that, in addition to the aforementioned sensor functions, also has a SOC (State of Charge) estimation function. The control device 150 can obtain the state of the battery 160 (e.g., temperature, current, voltage, and SOC) based on the output of the monitoring module 160a. SOC represents the remaining charge capacity, for example, expressed as 0 to 100% as the ratio of the current charge capacity to the charge capacity in a fully charged state.

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

[0083] MG20 is driven by PCU22, causing the drive wheels W of vehicle 1 to rotate. Furthermore, MG20 regenerates electricity and supplies the generated power to battery 160. PCU22 uses the power supplied from battery 160 to drive MG20. The number of driving motors (MG20) in vehicle 1 is arbitrary; it can be one, two, or more than three. The driving motors can be in-wheel motors. Figure 4 Only one drive wheel W is schematically shown, but the number of drive wheels W and the drive method in vehicle 1 are arbitrary. The drive method of vehicle 1 can be any of front-wheel drive, rear-wheel drive, or four-wheel drive.

[0084] The vehicle 1 has the following components on each wheel (including the drive wheel W): a braking device 30; a brake sensor 30a that detects the braking force applied to the wheel by the braking device 30; and a tire pressure sensor 30b that detects the tire pressure. The brake sensor 30a may be a hydraulic sensor that detects the hydraulic pressure applied to the brake pads (or wheel cylinders). The braking force (e.g., the hydraulic pressure corresponding to the braking force) detected by the four brake sensors 30a is output to the integrated control manager 115. Furthermore, the detection result of the tire pressure sensor 30b is also output to the integrated control manager 115.

[0085] A occupancy sensor 40 is configured to detect the presence of a person inside the vehicle 1. More specifically, the occupancy sensor 40 acquires information about the interior environment of the vehicle 1 for identification and outputs the acquired information to the integrated control manager 115. The occupancy sensor 40 includes at least one of a camera facing inwards and an infrared sensor. The occupancy sensor 40 may also include at least one of a seating sensor and a seatbelt sensor. The control device 150 can determine whether the vehicle 1 is occupied or unoccupied based on the output of the occupancy sensor 40.

[0086] The NAVI170 is configured to include a touch panel display, a GPS module, and a storage device (none shown). The storage device stores map information. The touch panel display accepts input from users inside the vehicle or displays maps and other information. The GPS module is configured to receive signals from GPS satellites (not shown) (hereinafter referred to as "GPS signals"). The NAVI170 can use GPS signals to determine the location of vehicle 1. The NAVI170 is configured to display the location of vehicle 1 on a map in real time. The NAVI170 is configured to perform a path search, referring to map information, to find the best route (e.g., the shortest route) from the current location of vehicle 1 to a destination. The NAVI170 can update map information sequentially via OTA.

[0087] The reader 180 is configured to read specified identification information from an image. More specifically, the reader 180 captures an image, extracts a specified code from the image, and performs decoding processing. The code extracted from the image is converted into specified identification information through the aforementioned decoding processing. Then, the reader 180 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 can also be an RFID (Radio Frequency Identification) reader.

[0088] The vehicle manager uses server 500 to manage vehicle 1. In this embodiment, only vehicle 1 is mentioned, but the vehicle manager could also use server 500 to manage many vehicles. The vehicle manager can provide both passenger transport services and vehicle dispatch services. Server 500 can also manage the service usage fees for each user.

[0089] Vehicle 1 provides services autonomously without a driver. That is, there is no vehicle manager in Vehicle 1. Essentially, only users ride in Vehicle 1, and when all users disembark, Vehicle 1 becomes unmanned. Vehicle 1 can, for example, travel autonomously along a pre-determined route within its operating area, similar to a dedicated bus. Furthermore, Vehicle 1 can also determine its route based on each request and execute autonomous driving according to the determined route (on-demand route). In the autonomous driving of Vehicle 1, the execution... Figure 3 The process shown involves the control unit 150 controlling various systems of the vehicle 1 according to instructions from the ADK200 (e.g., Figure 2 The braking system 121, steering system 122, powertrain system 123, active safety system 125, and body system 126 are shown.

[0090] Server 500 can identify the user currently using vehicle 1 and report information related to that user to the vehicle manager. Server 500 manages information (user information) related to each user registered in storage device 503. Each user is assigned an identification information (user ID), which Server 500 uses to distinguish and manage user information. In this embodiment, each user registered with server 500 carries a mobile terminal UT. User information includes, for example, vehicle repair skill information indicating the user's level of vehicle repair skills, driving skill information indicating the user's level of driving skills, and the address of the mobile terminal UT carried by the user. Driving skill information indicates whether the user has a license to manually drive vehicle 1 and their driving proficiency.

[0091] An application software (hereinafter referred to as the "mobile application") for using vehicle 1 is installed in the mobile terminal UT. When a user uses vehicle 1, the mobile terminal UT displays an image containing the user's identification information (user ID). Furthermore, when the user places the mobile terminal UT displaying the image on the reader 180 of vehicle 1, the user ID read by the reader 180 is sent from vehicle 1 to server 500. Server 500 determines the user using vehicle 1 based on the received user ID. Server 500 retrieves the user information corresponding to the user ID from storage device 503 according to a request from the vehicle manager and displays it on HMI 504. In addition, server 500 sends information related to the user using vehicle 1 to vehicle 1 according to a request from vehicle 1. It should be noted that, in order to prevent improper use of vehicle 1, doors (ticket gates) can be installed at the entrances and exits (boarding / alighting points) of vehicle 1. Furthermore, the doors can be configured such that they open when the reader 180 successfully reads the user ID and close again when the user passes through.

[0092] The control device 150 includes a diagnostic unit 51 and a response processing unit 52. In the control device 150, these units are implemented, for example, by a processor 151 and a program executed by the processor 151. However, this is not a limitation; these units may also be implemented using dedicated hardware (electronic circuitry).

[0093] In the autonomous driving of vehicle 1, diagnostic unit 51 determines whether an abnormality has occurred in vehicle 1. For example, diagnostic unit 51 can determine that an abnormality has occurred in vehicle 1 when any of the detection values ​​of various sensors mounted on vehicle 1 show an abnormal value. In addition, diagnostic unit 51 can also determine that an abnormality has occurred in vehicle 1 if an abnormality is detected by an abnormality sensor mounted on vehicle 1 (e.g., a leakage current sensor, a circuit breaker sensor, or a detachment sensor not shown).

[0094] Next, the diagnostic unit 51 determines whether the vehicle 1, which has experienced an anomaly, can continue driving via autonomous driving. Then, for the vehicle 1 that has experienced an anomaly and can no longer continue driving via autonomous driving, the diagnostic unit 51 determines whether the vehicle 1 can be repaired on the spot and whether the vehicle 1 can be driven manually. The response processing unit 52 is configured to perform prescribed processing based on the determination results obtained by the diagnostic unit 51.

[0095] If an anomaly is detected by the vehicle 1 during autonomous driving, the control device 150 performs the following operations. Figure 5 The series of processes shown. Figure 5This is a flowchart illustrating the process performed by the control device 150 when an anomaly occurs in vehicle 1 during autonomous driving. It should be noted that the judgment processes (S11, S13) in the flowchart are performed by the diagnostic unit 51, and the processes based on the judgment results (S12, S131, S132, S15) are performed by the response processing unit 52.

[0096] Reference Figures 1-4 Simultaneously refer to Figure 5 In S11, the control device 150 determines whether the vehicle 1, which has experienced an anomaly, can continue driving via autonomous driving. If the vehicle 1 can continue driving via autonomous driving (yes in S11), in S15, the vehicle 1 continues to move towards the designated location while maintaining autonomous driving. The control device 150 and ADK200 cooperate to perform autonomous driving control (see reference). Figure 3 A designated location is established for performing repair work on vehicle 1 (operations to eliminate abnormal factors from vehicle 1). This designated location can be either the dealership of vehicle 1 or an auto repair shop. When vehicle 1 arrives at the designated location, repair work is performed on vehicle 1. As a result, vehicle 1 returns to its normal state (a state without abnormalities). When processing S15 is executed, Figure 5 The series of processes shown has ended.

[0097] If vehicle 1 is unable to continue driving via autonomous driving (not in S11), in S12, control device 150 causes a designated reporting device (e.g., at least one of NAVI 170 and HMI 230) to perform a first report indicating that an anomaly has occurred in vehicle 1 and a second report requesting manual stopping of vehicle 1. Control device 150 may sound an alarm via the first report. The designated reporting device may perform the second report via at least one of voice and display.

[0098] Next, in S13, the control device 150 determines whether manual driving operation has been performed on vehicle 1 according to the request (second report processing) in S12. If manual driving operation has been performed on vehicle 1 (yes in S13), in S131, vehicle 1 switches from autonomous mode (automatic driving) to manual mode (manual driving), and the user inside the vehicle can stop vehicle 1 by manual driving. At this time, the acceleration of vehicle 1 achieved by manual driving can also be limited. Furthermore, if it is determined that there is a possibility of collision while vehicle 1 is driving manually, the active safety system 125 stops vehicle 1. While vehicle 1 is driving manually, the control device 150 requests the user inside the vehicle to stop the vehicle by manual driving through the aforementioned reporting device. Then, when vehicle 1 is stopped by manual driving, the process proceeds to S14.

[0099] If no manual driving operation is performed on vehicle 1 (no in S13), the process proceeds to S132. For example, if vehicle 1 is unmanned, it is determined to be no in S13. Even if vehicle 1 is manned, it is determined to be no in S13 if no manual driving operation is performed on vehicle 1. Even if a predetermined time has elapsed since the request (second report processing) in S12, and no manual driving operation has been performed on vehicle 1, the control device 150 may determine to be no in S13.

[0100] In S132, the control device 150 stops the vehicle 1 via the braking system 121. Specifically, the control device 150 outputs a braking command to the braking 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.

[0101] In S14, a process for repairing vehicle 1 is performed, specifically, as described below. Figure 6 The series of processes shown. Figure 6 This is a flowchart showing the details of S14. It should be noted that the judgment processes (S21, S22) in the flowchart are executed by the diagnostic unit 51, and the processes based on the judgment results (S24, S25) are executed by the response processing unit 52.

[0102] Reference Figures 1-4 Simultaneously refer to Figure 6In S21, the control device 150 determines whether a handling method for an anomaly occurring in vehicle 1 is apparent. The storage device 153 stores pre-assumed anomaly items and their handling methods in association with error codes. If an anomaly occurring in vehicle 1 matches any of these items, the control device 150 determines in S21 that it is, and displays the error code and handling method on a designated reporting device (e.g., at least one of NAVI 170 and HMI 230). The error code indicates the type of anomaly. Then, in S22, the next diagnostic step is performed.

[0103] In step S22, the control device 150 determines whether the malfunctioning vehicle 1 can be repaired within a specified time. Specifically, the control device 150 requests information (user information) related to the user currently using vehicle 1 from the server 500 and uses the user information received from the server 500 to make the determination in S22. The control device 150 can make the determination in S22 based on the difficulty of the repair operation represented by the error code and the vehicle repair skill represented by the user information. If the difficulty of the repair operation exceeds a predetermined first level, the control device 150 can determine "no" in S22. If the user's vehicle repair skill is below a predetermined second level, the control device 150 can determine "no" in S22. If the difficulty of the repair operation does not exceed the first level and the user's vehicle repair skill reaches the second level, the control device 150 can determine "yes" in S22. It should be noted that if vehicle 1 is unattended, the determination in S22 will be "no".

[0104] If it is determined that the malfunctioning vehicle 1 can be repaired within the specified time (in S22, this is true), then in S23, the vehicle 1 is repaired on the spot. The determination being true in both S21 and S22 means that the diagnostic unit 51 determines that the vehicle 1 can be repaired on the spot (at the parking position). Figure 7 This is a flowchart showing the details of S23. It should be noted that the judgment processes (S33, S35, S36) in the flowchart are executed by the diagnostic unit 51, and the processes based on the judgment results (S34, S37, S38) are executed by the response processing unit 52.

[0105] Reference Figures 1-4 Simultaneously refer to Figure 7 In S31, the control device 150 sets the state of vehicle 1 (e.g., in...) Figure 6The error codes and exceptions identified in S21 are displayed on a designated reporting device. In this embodiment, the designated reporting device in S31 is a mobile terminal UT carried by a user using vehicle 1. The mobile terminal UT can operate according to a mobile application. However, it is not limited to this; a terminal mounted on vehicle 1 (e.g., NAVI170 or HMI230) may be used instead of the mobile terminal UT, or a terminal mounted on vehicle 1 (e.g., NAVI170 or HMI230) may be used in addition to the mobile terminal UT.

[0106] In the next step, S32, the control device 150 displays a guide indicating the repair process on the mobile terminal UT. The guide for each error code can be pre-stored in the storage device 153. Alternatively, the control device 150 can also retrieve the guide from the server 500. In this embodiment, in S32, Figure 7 The screen D1 shown is displayed on the mobile terminal UT. Screen D1 displays the status of vehicle 1, instructions, stop button B1, help button B2, and complete button B3.

[0107] In the next step, S33, the control device 150 determines whether the user has operated the help button B2. If the help button B2 has been operated (yes in S33), in S34, the control device 150 provides voice guidance to the user. For example, voice guidance can be implemented using AI (artificial intelligence). The AI ​​used for voice guidance can be pre-stored in the storage device 153. For example, the user can transmit the guide number and step number to the AI ​​via a mobile terminal UT, thereby allowing the AI ​​to provide explanations (suggestions) related to the corresponding task. However, this is not limited to this; a conversation with the operator (human) can also be used instead of voice guidance implemented using AI.

[0108] When the aforementioned voice guidance (S34) ends, the process proceeds to S35. Furthermore, if the help button B2 on screen D1 is not operated (no in S33), voice guidance (S34) is not performed, and the process proceeds to S35. In S35, the control device 150 determines whether the operation abort condition is met. If the operation abort condition is not met (no in S35), in S36, the control device 150 determines whether the repair operation has been completed.

[0109] In this embodiment, the job abort condition is met when the user operates the abort button B1 on the D1 screen. Operating the abort button B1 on the mobile terminal UT is equivalent to an input indicating job abort. Furthermore, the job abort condition is also met if a predetermined time has elapsed since the malfunction occurred in vehicle 1 before the repair work is completed. For example, the start... Figure 7The timing of the series of processes shown is considered to be the timing when an anomaly occurs in vehicle 1. When the operation abort condition is met (yes in S35), the operations in S38 and S39 are performed in accordance with the... Figure 6 The processing is the same as the case where the condition in S22 is negative (i.e., the same as described later). Figure 6 After the same processing as S25 and S26, Figure 7 The series of processes shown here ends. That is, when the work stoppage condition is met, the diagnostic unit 51 withdraws its judgment that the abnormal vehicle 1 can be repaired on the spot, and judges that the abnormal vehicle 1 cannot be repaired on the spot.

[0110] In this embodiment, when the user presses the Complete button B3 on screen D1, the control device 150 checks whether vehicle 1 has become normal (whether the abnormal factors have been eliminated from vehicle 1). Then, if the control device 150 determines that vehicle 1 has become normal (repaired), it determines "yes" in S36. Conversely, if the control device 150 determines that vehicle 1 has not become normal (not repaired), it determines "no" in S36. Furthermore, if the user does not press the Complete button B3, it also determines "no" in S36. When it determines "no" in S36, the process returns to S32.

[0111] If the repair work has been completed (yes in S36), then in S37, control device 150 restarts the automatic driving of vehicle 1. Figure 7 The series of processes shown (and thus, Figure 6 End of S23). Figure 5 S14 ends, Figure 5 The series of processes shown has ended.

[0112] Refer again Figures 1-4 Simultaneously refer to Figure 6 If either S21 or S22 results in a negative result, it means that the diagnostic unit 51 determines that vehicle 1 cannot be repaired on-site (at the parking position). In this case, to avoid obstructing traffic, the repair work on vehicle 1 is performed after moving vehicle 1 to the work site. The method of moving vehicle 1 will be described later. In each of S24 and S25 described below, the work site is determined.

[0113] If the anomaly occurring in vehicle 1 is not a pre-predicted anomaly (does not meet any of the anomaly items stored in storage device 153), control device 150 determines "no" in S21 and proceeds to S24. In S24, control device 150 sets the vehicle 1's dealership as the work location. Ideally, for anomalies where the handling method is not obvious, handling should be performed at the dealership. By performing repair work at the dealership, it is also easier to appropriately handle anomalies where the handling method is not obvious.

[0114] If it is determined that the malfunctioning vehicle 1 cannot be repaired within the specified time (not in S22), the process proceeds to S25. In S25, the control device 150 sets the backyard as the work site. The backyard is a place around the current location of vehicle 1 that does not obstruct traffic (e.g., a rest area or parking lot).

[0115] When a work site is set in either S24 or S25, the movement and repair of vehicle 1 are carried out in S26. Figure 8 This is a flowchart showing the details of S26. It should be noted that the judgment processes (S41, S42) in the flowchart are executed by the diagnostic unit 51, and the processing based on the judgment results (S43 to S46) is executed by the response processing unit 52.

[0116] Reference Figures 1-4 Simultaneously refer to Figure 8 In step S41, the control unit 150 determines whether the vehicle 1 can be switched to manual driving. The control unit 150 can determine whether the vehicle 1 can be switched to manual driving based on whether an anomaly occurring in the vehicle 1 would hinder manual driving. Examples of anomalies that would not hinder manual driving include anomalies related to automatic driving control, such as a run-flat tire leaking air. Examples of anomalies that would hinder manual driving include a drop in brake fluid pressure.

[0117] In the next step, S42, the control device 150 determines whether a person capable of manually driving the vehicle 1 is riding in the vehicle 1. Specifically, the control device 150 uses the output of the occupancy sensor 40 to determine whether someone is riding in the vehicle 1. If the vehicle 1 is unoccupied, the determination is negative in S42. If the vehicle 1 is occupied, the control device 150 requests information (user information) related to the user using the vehicle 1 from the server 500. Then, the control device 150 uses the user information received from the server 500 to determine whether the person in the vehicle can manually drive the vehicle 1. In this embodiment, if the person in the vehicle does not have a license to manually drive the vehicle 1, the determination is negative in S42. Furthermore, if the person's driving skill level is below a specified level (e.g., if the person in the vehicle is a licensed driver), the determination is also negative in S42. If the person's driving skill level reaches the specified level, the control device 150 can determine positive in S42. Determining positive in both S41 and S42 means that the diagnostic unit 51 determines that the vehicle 1 can be driven manually.

[0118] When both S41 and S42 are determined to be true, in S43, the control device 150 sets the vehicle 1 to a state where it can be controlled manually and performs driving assistance processing. Specifically, the control device 150 can enable the vehicle 1 to reach its destination (in...) by manual driving. Figure 6 S24, S25 Figure 7 (any of the work sites set in S38) and the surrounding area Figure 1 It is displayed on NAVI170. In addition, it can also enable ADAS (Advanced Driver Assistance Systems) used in vehicle 1.

[0119] In S45, following the processing in S43, vehicle 1 moves towards the work site (destination) by manual driving. In S45, control unit 150 performs driving control of vehicle 1 according to the user's driving operation. The user can perform manual driving while receiving driving assistance. Then, when vehicle 1 arrives at the work site, in S46, control unit 150 performs processing for repair response. If the work site is a backyard, control unit 150 requests the dispatch of workers from the vehicle 1's dealership. This dispatch request can be made before vehicle 1 arrives at the work site (backyard). After vehicle 1 arrives at the work site, in S46, control unit 150 can display the status of vehicle 1 on a designated reporting device (e.g., at least one of NAVI 170 and HMI 230).

[0120] A negative result in either S41 or S42 means that the diagnostic unit 51 determines that vehicle 1 cannot be driven manually. When a negative result is found in either S41 or S42, in S44, the control device 150 performs a rescue vehicle arrangement to move vehicle 1 to a rescue vehicle. Specifically, the control device 150 sends a signal requesting the movement of a rescue vehicle (hereinafter also referred to as a "rescue vehicle request signal") to the terminal of the rescue vehicle service provider. The rescue vehicle request signal includes the current location (parking position) and destination (in this embodiment, at...) of vehicle 1. Figure 6 S24, S25 Figure 7 (The work site set in any of S38). For rescue vehicle service providers, when accepting a request to move a rescue vehicle, for example, to make Figure 8 The rescue vehicle 300 shown proceeds to vehicle 1. Then, vehicle 1 is towed by the rescue vehicle 300 and transported to the work site (destination).

[0121] In S45, following the process in S44, the rescue vehicle 300 tows the vehicle 1 toward the work site (destination). In S45, the control unit 150 remains in a state capable of towing the vehicle 1 (rescue vehicle mode). Then, when the vehicle 1 arrives at the work site, in S46, the control unit 150 performs procedures for repair response. The procedures in S46 are the same as when the vehicle 1 is moved manually.

[0122] When the above S46 process is executed, Figure 8 The series of processes shown (and thus, Figure 6 S26 or Figure 7 End of S39). Figure 5 S14 ends, Figures 5-8 The series of processes shown has ended.

[0123] As described above, the vehicle management method of this embodiment includes Figures 5-8 The processing is shown. In this embodiment, the integrated control manager 115 (control device 150) includes an example of the "computer" of this disclosure.

[0124] exist Figure 6 In S11, the control device 150 determines whether the vehicle 1 in autonomous driving mode has experienced an anomaly that prevents it from continuing to drive autonomously. Figure 8 In S21 and S22, the control device 150 determines whether the malfunctioning vehicle 1 can be repaired on the spot. Figure 8In S41 and S42, the control device 150 determines whether the malfunctioning vehicle 1 can be driven manually. Then, if the malfunctioning vehicle 1 cannot be repaired on the spot, and the malfunctioning vehicle 1 cannot be driven manually (in... Figure 4 If either S21 or S22 is negative, and... Figure 6 (If either S41 or S42 is negative), in Figure 6 In step S44, the control unit 150 arranges a rescue vehicle for moving vehicle 1 to a rescue vehicle position. According to this vehicle management method, when an anomaly occurs in a vehicle operating in autonomous driving, appropriate action can be taken against the vehicle as early and as possible.

[0125] The functions of the control device 150 in the above embodiments (in particular, Figure 7 The functions of the diagnostic unit 51 and the response processing unit 52 shown can also be installed in the computer 210 of the ADK200. For example, the computer 210 can replace the control device 150 to perform these functions. Figure 8 The processing is shown. In this manner, Figure 4 The process shown includes, Figure 9 and Figure 5 The respective processing is also performed by computer 210. Computer 210 can also instruct the control unit 150 on the required processing. A vehicle control interface is provided in the base vehicle 100, thereby facilitating the installation and removal of ADK200. By installing the functions of the aforementioned diagnostic unit 51 and response processing unit 52 into computer 210, these functions are easily provided to the vehicle. In such a vehicle, the computer 210 of ADK200 is equivalent to an example of the "computer" of this disclosure.

[0126] The functions of the control device 150 in the above embodiments (in particular, Figure 9 The functions of the diagnostic unit 51 and the response processing unit 52 shown can also be installed on a mobile terminal UT. For example, the diagnostic unit 51 and the response processing unit 52 can be implemented through a mobile application.

[0127] The control device 150 of vehicle 1 can also perform Figure 5 The process shown is used to replace Figure 5 The processing shown. Figure 9 It means Figure 5 The flowchart shows a first variation of the process. Except that S14A is used instead of S14 (… Figure 9 )outside, Figure 6 The processing shown is the same as Figure 4 The processing shown is the same. (Refer to...) Figure 10In S14A, the control device 150 requests processing from the mobile terminal UT carried by the user using vehicle 1 to repair vehicle 1. The mobile terminal UT executes the request from vehicle 1 (control device 150). Figure 5 The process is illustrated. The mobile terminal UT obtains information from vehicle 1 and server 500 as needed, or requests vehicle control from vehicle 1. In the first variation described above, the mobile terminal UT includes an example of the "computer" of this disclosure.

[0128] The functions of the control device 150 in the above embodiments (in particular, Figure 10 The functions of the diagnostic unit 51 and the response processing unit 52 shown can also be installed on a local (on-premises) server (server 500). Furthermore, the functions of the control device 150 can also be installed in the cloud via cloud computing.

[0129] The control device 150 of vehicle 1 can also perform Figure 5 The process shown is used to replace Figure 5 The processing shown. Figure 10 It means Figure 5 The flowchart shows a second variation of the process. Except that S14B is used instead of S14 (… Figure 10 )outside, Figure 6 The processing shown is the same as Figures 5-10 The processing shown is the same. (Refer to...) Figure 5 In S14B, the control device 150 requests the server 500 for processing to repair the vehicle 1. The server 500 executes the request from the vehicle 1 (control device 150). Figure 9 The processing is illustrated. Server 500 may obtain information from vehicle 1 and mobile terminal UT as needed, or request vehicle control from vehicle 1. In the second variation described above, server 500 includes an example of a "computer" of this disclosure.

[0130] Figure 10 The processing methods shown can be modified appropriately. For example, in Figure 1 , Figure 2 or Figure 4 If the determination in S11 is negative, automatic stop can be executed without making a manual stop request (S132).

[0131] The vehicle's configuration is not limited to the configuration described in the above embodiments (see reference). ​ , ​ as well as ​The base vehicle can also have autonomous driving capabilities without aftermarket installations. The vehicle can be equipped with solar panels and even have flight capabilities. It can also be equipped with chargers for on-the-go charging or contactless charging. The vehicle is not limited to passenger cars; it can also be a bus or truck. The vehicle can also be a multi-purpose vehicle customized to the user's intended use. It can also be a mobile shop vehicle or agricultural machinery. The vehicle can also be a small BEV (Bike Electric Vehicle) with one passenger (e.g., Micro Palette, a small delivery robot).

[0132] The above-described implementation methods and variations can be combined arbitrarily.

[0133] The embodiments disclosed herein should be considered illustrative rather than limiting in all respects. The scope of the technology shown in this disclosure is not illustrated by the description of the foregoing embodiments, but by the claims, and is intended to include all modifications within the meaning and scope equivalent to the claims.

Claims

1. A computer, comprising: The diagnostic department determines whether a vehicle that has malfunctioned and is unable to continue driving via autonomous driving can be repaired on the spot and whether the vehicle can be driven manually. The response processing unit performs prescribed processing based on the judgment results obtained by the diagnostic unit. as well as A storage device, wherein the storage device stores, in association with error codes, pre-assumed exception items and their corresponding handling methods. The diagnostic unit is configured to determine whether a handling method for the abnormality is obvious and whether the vehicle with the abnormality can be repaired within a specified time. If the abnormality of the vehicle meets any of the above criteria, the diagnostic unit determines that a handling method for the abnormality is obvious. If the method for handling the abnormality is obvious and the vehicle that has experienced the abnormality can be repaired within the specified time, the diagnostic unit determines that the vehicle that has experienced the abnormality can be repaired on the spot.

2. The computer according to claim 1, wherein, The response unit is configured to, when the diagnostic unit determines that the vehicle cannot be repaired on-site and the vehicle cannot be driven manually, arrange for a rescue vehicle to be moved to a rescue vehicle location. In cases where the diagnostic unit determines that the vehicle can be repaired on the spot, or where the diagnostic unit determines that the vehicle can be driven manually, the response handling unit will not arrange for a rescue vehicle.

3. The computer according to claim 1, wherein, If the diagnostic unit determines that the vehicle can be repaired on the spot, the response processing unit displays a guide indicating the repair process on at least one of the terminals installed in the vehicle and the terminal of the user using the vehicle.

4. The computer according to claim 3, wherein, When the user inputs an indication to stop the operation on the terminal displaying the instructions, the diagnostic unit withdraws its judgment that the vehicle with the malfunction can be repaired on the spot, and determines that the vehicle with the malfunction cannot be repaired on the spot.

5. The computer according to claim 4, wherein, The diagnostic unit is configured to use user information related to the user using the vehicle to determine whether the vehicle, which has experienced the abnormality, can be repaired within the specified time.

6. The computer according to any one of claims 1 to 5, wherein, The diagnostic 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 riding in the vehicle. When a person capable of manually driving the vehicle is riding in the vehicle, the diagnostic unit determines that the vehicle can be driven manually.

7. The computer according to claim 6, wherein, The diagnostic unit is configured to use the output of a sensor that detects the presence of a person in the vehicle and user information related to the user using the vehicle to determine whether a person capable of manually driving the vehicle is riding in the vehicle.

8. The computer according to any one of claims 1 to 5, wherein, If the vehicle is unable to continue driving via autonomous driving due to an anomaly, but can be driven manually, the response processing unit performs driving assistance processing.

9. A vehicle equipped with a control device, wherein, The vehicle also features: Autonomous driving kits; and The vehicle control interface mediates the exchange of signals between the control device and the autonomous driving suite. The autonomous driving suite 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 the instructions from the autonomous driving suite. The control device is configured to send signals indicating the state of the vehicle to the autonomous driving suite via the vehicle control interface. The control device or the autonomous driving kit includes a computer as claimed in any one of claims 1 to 8.

10. A server comprising a computer as claimed in any one of claims 1 to 8.

11. A mobile terminal comprising a computer as claimed in any one of claims 1 to 8.

12. A vehicle management method, comprising: The computer determines whether a vehicle in autonomous driving mode has encountered an anomaly that prevents it from continuing to drive autonomously. The computer determines whether the vehicle that has experienced the abnormality can be repaired on the spot; The computer determines whether the vehicle that experienced the anomaly can be driven manually; and If the vehicle experiencing the malfunction cannot be repaired on-site and cannot be driven manually, the computer arranges for a rescue vehicle to be moved to the vehicle. The computer stores pre-assigned exceptions and their corresponding handling methods in association with error codes. The computer is configured to determine whether a handling method for the anomaly is obvious and whether it can repair the vehicle that experienced the anomaly within a specified time. The computer determines that a handling method for the anomaly is obvious if the anomaly occurs in the vehicle and meets either of the above criteria. If the method for handling the anomaly is obvious and can repair the vehicle that has experienced the anomaly within the specified time, the computer determines that the vehicle that has experienced the anomaly can be repaired on the spot.

Images