Server and information processing method

Abstract

To reduce user's disadvantages accompanied by maintenance of a vehicle with an automated driving system mounted on a vehicle platform.SOLUTION: A vehicle server 7 is a server for setting a maintenance schedule of a vehicle 1 with an ADK 2 mounted on a VP 3, and includes a processor 71, and a memory 72 storing a program executable by the processor 71. The processor 71 sets a maintenance schedule in a time zone in which maintenance of the ADK 2 and maintenance of the VP 3 can be continuously executed when there is a prescribed abnormality that can maintain the ADK 2 even if the abnormality of the ADK 2 does not remove the ADK 2 from the VP3 in the case that the abnormality of the ADK 2 and an abnormality of the VP3 occur.SELECTED DRAWING: Figure 13

Description

[Technical field]

[0001] The present disclosure relates to a server and an information processing method, and more particularly to an information processing technique for managing vehicles. [Background technology]

[0002] JP 2021-5292 A (Patent Document 1) discloses an information processing device that makes it easier to improve user convenience and promote the use of rental vehicles regarding vehicle maintenance and rental vehicle reservations. [Prior art documents] [Patent documents]

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

[0004] In recent years, technological development for autonomous driving of vehicles has progressed. There are also known companies that specialize in developing autonomous driving systems that comprehensively control autonomous driving. An autonomous driving system developed separately from the vehicle platform (the vehicle itself) is mounted on the vehicle platform (so-called external). Then, autonomous driving is realized when the vehicle platform operates according to commands from the external autonomous driving system.

[0005] The present inventors have noticed that the following problems may arise if external autonomous driving systems become widespread in the future. If some abnormality occurs in the autonomous driving system, maintenance (including inspection, repair, and replacement) of the autonomous driving system may be required. On the other hand, an abnormality may occur in the vehicle platform, requiring maintenance of the vehicle platform. When such maintenance becomes necessary, the user takes the vehicle to a facility such as a dealer or a maintenance shop and requests maintenance.

[0006] During maintenance of the autonomous driving system and / or the vehicle platform, the vehicle is unavailable, which may cause inconvenience to users. Therefore, it is desirable to reduce the inconvenience to users associated with maintenance as much as possible.

[0007] The present disclosure has been made to solve the above-mentioned problems, and one of the objectives of the present disclosure is to reduce the inconvenience to users associated with the maintenance of a vehicle having an autonomous driving system mounted on a vehicle platform. [Means for solving the problem]

[0008] (1) A server according to an aspect of the present disclosure sets a maintenance schedule for a vehicle having an autonomous driving system mounted on a vehicle platform. The server includes a processor and a memory storing a program executable by the processor. When an abnormality in the autonomous driving system and an abnormality in the vehicle platform occur, if the abnormality in the autonomous driving system is a predetermined abnormality that allows the autonomous driving system to be maintained without removing the autonomous driving system from the vehicle platform, the processor sets the maintenance schedule for a time period during which maintenance of the autonomous driving system and maintenance of the vehicle platform can be performed consecutively.

[0009] (2) The specified abnormalities include abnormalities that can be observed from the outside of the automated driving system. (3) The autonomous driving system includes sensors that recognize the vehicle's environment. Abnormalities that can be repaired from the outside include abnormalities caused by dirt on the sensors.

[0010] In the above configurations (1) to (3), the maintenance schedule is set during a time period when maintenance of the autonomous driving system and maintenance of the vehicle platform can be carried out consecutively. In this way, there is no idle time during which the vehicle cannot be used between the maintenance of the autonomous driving system and the maintenance of the vehicle platform. Therefore, the above configurations (1) to (3) can reduce the inconvenience to the user associated with maintenance of a vehicle on which an autonomous driving system is mounted on a vehicle platform.

[0011] (4) The processor extracts one or more candidate time slots during which maintenance of the autonomous driving system and maintenance of the vehicle platform can be performed consecutively from among available time slots in the maintenance schedule, and proposes the one or more extracted candidate time slots to the user terminal. When one of the one or more candidate time slots is selected by operation on the user terminal, the processor allocates the selected time slot to the maintenance of the autonomous driving system and the vehicle platform.

[0012] According to the configuration (4) above, one or more candidate time slots are proposed by the server, making it possible to carry out the maintenance of the autonomous driving system and the maintenance of the vehicle platform consecutively, and also making it easy for the user to select a time slot that is convenient for him or her.

[0013] (5) An information processing method according to another aspect of the present disclosure is an information processing method by a computer, the information processing method including a step of setting, by the computer, a maintenance schedule for a vehicle having an autonomous driving system mounted on a vehicle platform, the setting step including a step of setting a maintenance schedule for a time period in which maintenance of the autonomous driving system and maintenance of the vehicle platform can be performed consecutively when an abnormality of the autonomous driving system and an abnormality of the vehicle platform occur and the abnormality of the autonomous driving system is a predetermined abnormality that allows maintenance of the autonomous driving system without removing the autonomous driving system from the vehicle platform.

[0014] According to the method (5) above, similar to the configuration (1) above, it is possible to reduce the inconvenience to users associated with maintenance of a vehicle on which an autonomous driving system is mounted on a vehicle platform. Effect of the Invention

[0015] According to the present disclosure, it is possible to reduce the inconvenience to users associated with maintenance of a vehicle having an autonomous driving system mounted on a vehicle platform. [Brief description of the drawings]

[0016] [Figure 1]1 is a diagram illustrating an overall configuration of an information processing system according to an embodiment of the present disclosure. [Diagram 2] FIG. 2 shows the configuration of the autonomous driving kit and vehicle platform in more detail. [Diagram 3] FIG. 2 is a block diagram showing a typical hardware configuration of a dealer server. [Figure 4] FIG. 1 is a block diagram showing a typical hardware configuration of an ADK server. [Diagram 5] FIG. 2 is a block diagram showing a typical hardware configuration of a vehicle server. [Figure 6] FIG. 2 is a conceptual diagram showing a schematic configuration of a database relating to abnormality information of the autonomous driving kit. [Figure 7] FIG. 2 is a conceptual diagram showing a schematic configuration of a database relating to abnormality information of a vehicle platform. [Figure 8] FIG. 1 is a conceptual diagram of a maintenance schedule. [Figure 9] FIG. 13 is a diagram illustrating a method for setting a maintenance schedule for performing maintenance that does not require removing the autonomous driving kit from the vehicle platform. [Figure 10] FIG. 13 is a diagram showing an input screen for selecting a desired maintenance date. [Figure 11] FIG. 13 is a diagram showing an input screen for selecting a maintenance time slot. [Figure 12] FIG. 13 is a diagram showing a confirmation screen for a maintenance reservation. [Figure 13] FIG. 2 is a sequence diagram showing a process flow in the information processing system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0018] In this disclosure and its embodiments, "maintenance" of an autonomous driving system refers to any action for maintaining the autonomous driving system in a normal state or for restoring the autonomous driving system from an abnormal state to the normal state. Maintenance may include inspection, repair, adjustment, and replacement. The same applies to "maintenance" of a vehicle platform.

[0019] [Embodiment Mode] <Overall system configuration> 1 is a diagram illustrating a schematic overall configuration of an information processing system according to an embodiment of the present disclosure. The information processing system 100 manages a plurality of vehicles. In reality, a large number of vehicles can be managed, but for convenience of explanation, a specific vehicle 1 will be described below as an example. The vehicle 1 is an autonomous driving vehicle, and includes an autonomous driving kit (ADK) 2 and a vehicle platform (VP) 3.

[0020] The ADK2 creates a driving plan for the vehicle 1. The ADK2 outputs various control requests for driving the vehicle 1 according to the driving plan to the VP3 according to an API (Application Program Interface) defined for each control request. The ADK2 also receives various signals indicating the vehicle state (VP3 state) from the VP3 according to an API defined for each signal. The ADK2 then reflects the vehicle state in the driving plan. The ADK2 is attached to the rooftop of the VP3, for example. The ADK2 can also be removed from the VP3. The ADK2 corresponds to the "autonomous driving system" according to the present disclosure.

[0021] The VP3 executes driving control in the autonomous driving mode according to control requests from the ADK2. When the ADK2 is removed, the VP3 can also execute driving control in the manual mode (driving control according to the driver's operation).

[0022] The ADK 2 and VP 3 transmit various information (ADK abnormality information, VP abnormality information, etc., which will be described later) to a server in the information processing system 100. The detailed configurations of the ADK 2 and VP 3 will be described with reference to FIG.

[0023] The user of the vehicle 1 is typically an individual user, but is not limited to this. The user may also be a business that provides an autonomous driving service using the vehicle 1 (such as a taxi business, a rental car business, a car sharing business, or a ride sharing service business). The user has a user terminal 4. The user terminal 4 is a smartphone, a tablet, a personal computer, or the like. The user terminal 4 displays information received from a server in the information processing system 100. In addition, the user terminal 4 accepts user operations and transmits the results of the user's selection to the server.

[0024] The information processing system 100 includes a dealer server 5, an ADK server 6, and a vehicle server 7. The servers are connected to each other via a network so as to be able to communicate with each other bidirectionally.

[0025] The dealer server 5 is a server operated by a dealer (sales store) of the vehicle 1. In this example, the vehicle 1 (ADK2 and VP3) is maintained by the dealer. Therefore, the dealer server 5 manages a maintenance schedule (see FIG. 8) for the vehicle 1. The dealer server 5 transmits the maintenance schedule to the vehicle server 7, for example, in response to a request from the vehicle server 7.

[0026] The vehicle 1 may also be maintained by another facility such as a maintenance shop. In that case, the information processing system 100 may include, instead of or in addition to the dealer server 5, another server operated by the facility.

[0027] The ADK server 6 is, for example, a server operated by the manufacturer of the ADK 2. The ADK server 6 may be operated by a maintenance management company for the ADK 2. The ADK server 6 collects information on abnormalities in the ADK 2 from the ADK 2. Hereinafter, this information is also referred to as "ADK abnormality information." The ADK server 6 includes a database (see FIG. 6) for storing ADK abnormality information collected from multiple vehicles 1. The ADK server 6 transmits the ADK abnormality information to the dealer server 5 prior to maintenance of the ADK 2. This enables the dealer to perform appropriate maintenance of the ADK 2. Note that the ADK abnormality information is not notified from the ADK 2 to the VP 3.

[0028] The vehicle server 7 is, for example, a server operated by the manufacturer of the vehicle 1. The vehicle server 7 collects information regarding abnormalities in the VP3 from the VP3. Hereinafter, this information is also referred to as "VP abnormality information." The vehicle server 7 has a database (see FIG. 6) for storing VP abnormality information from multiple vehicles 1. Prior to maintenance of the VP3, the vehicle server 7 transmits the VP abnormality information to the dealer server 5. This enables the dealer to perform appropriate maintenance of the VP3.

[0029] The vehicle server 7 has user registration information for the vehicle 1. The user registration information includes information relating to the dealer in charge of sales and maintenance of the vehicle 1, in addition to information relating to associating the user with the vehicle 1. Therefore, the vehicle server 7 can quickly identify the dealer in charge of maintenance of the vehicle 1 when an abnormality occurs in the vehicle 1.

[0030] When an abnormality requiring maintenance occurs in the ADK2, the ADK server 6 transmits a maintenance request for the ADK2 along with the ADK abnormality information to the vehicle server 7. Hereinafter, this request is also referred to as an "ADK maintenance request." When the vehicle server 7 receives the ADK maintenance request, it creates a proposal for a maintenance reservation by referring to the maintenance schedule acquired from the dealer server 5. The vehicle server 7 transmits the created proposal to the user terminal 4. The user operates the user terminal 4 to select the maintenance reservation that he or she desires. The user terminal 4 transmits the maintenance reservation selected by the user to the vehicle server 7. The vehicle server 7 outputs a notification to the dealer server 5 confirming the maintenance reservation. As a result, the maintenance schedule is updated in the dealer server 5.

[0031] 1, it has been described that the vehicle server 7 proposes a maintenance reservation to the user terminal 4. In this case, the vehicle server 7 corresponds to the "server" according to the present disclosure. However, instead of the vehicle server 7, the dealer server 5 may propose a maintenance reservation. In that case, an ADK maintenance request is transmitted from the ADK server 6 to the dealer server 5, and a VP3 maintenance request is transmitted from the vehicle server 7 to the dealer server 5. Also, the ADK server 6 may propose a maintenance reservation.

[0032] Each of the dealer server 5, the ADK server 6, and the vehicle server 7 may be a server owned by the business operator. Each server may be a shared server shared by multiple business operators including the business operator. Each server may be a cloud server provided by a cloud server management company.

[0033] <Vehicle configuration> 2 is a diagram showing in more detail the configuration of the ADK 2 and the VP 3. The ADK 2 includes a computer 21, a recognition sensor 22, a posture sensor 23, a sensor cleaner 24, an HMI (Human Machine Interface) 25, and a communication module 26.

[0034] VP3 includes a vehicle control interface box (VCIB) 31 and a base vehicle 32. The base vehicle 32 includes an ECU 321, a brake system 322, a steering system 323, a powertrain system 324, an active safety system 325, a body system 326, and a digital communication module (DCM) 327. The brake system 322 includes brake systems 322A and 322B. The steering system 323 includes steering systems 323A and 323B. The powertrain system 324 includes an electric parking brake (EPB) system 324A, a parking lock (P lock) system 324B, and a propulsion system 324C.

[0035] The computer 21 is redundant and includes two processors 211, 212. The computer 21 (each of the processors 211, 212) acquires data on the environment of the vehicle 1 using the recognition sensor 22 when the vehicle 1 is autonomously driven. The computer 21 also acquires data on the attitude, behavior, and position of the vehicle 1 using the attitude sensor 23 when the vehicle 1 is autonomously driven. Furthermore, the computer 21 is communicably connected to the VCIB 31. The computer 21 acquires the vehicle state from the VP3 via the VCIB 31 and sets the next operation of the vehicle 1 (accelerate, decelerate, turn, etc.). The computer 21 outputs various commands for realizing the next operation to the VP3 via the VCIB 31.

[0036] The recognition sensor 22 is a sensor for recognizing the environment of the vehicle 1. The recognition sensor 22 includes at least one of, for example, a LIDAR (Laser Imaging Detection and Ranging), a millimeter wave radar, and a camera (none of which are shown). The LIDAR measures the distance and direction of an object by emitting, for example, an infrared pulse laser light and detecting the reflected light of the laser light from the object. The millimeter wave radar measures the distance and direction of an object by emitting millimeter waves and detecting the reflected wave of the millimeter waves from the object. The camera captures an image of the surroundings of the vehicle 1. The recognition sensor 22 corresponds to the "sensor" according to the present disclosure.

[0037] The attitude sensor 23 is a sensor for detecting the attitude, behavior, and position of the vehicle 1. The attitude sensor 23 includes, for example, an IMU (Inertial Measurement Unit) and a GPS (Global Positioning System) (neither shown). The IMU detects, for example, the acceleration in the forward / backward, left / right, and up / down directions of the vehicle 1, and the angular velocities in the roll, pitch, and yaw directions of the vehicle 1. The GPS identifies the position of the vehicle 1 using information received from multiple GPS satellites orbiting the Earth.

[0038] The sensor cleaner 24 is configured to remove dirt adhering to the above-mentioned various sensors (camera lenses, laser light irradiation parts, etc.) while the vehicle 1 is traveling by using a cleaning liquid, a wiper, etc. The HMI 25 is configured to be connected to an input / output device (not shown) such as a touch panel display provided on the base vehicle 32. The communication module 26 is configured to enable two-way data communication between the computer 21 and the ADK server 6.

[0039] The VCIB 31 is communicatively connected to the ADK 2 via a controller area network (CAN) or the like. The VCIB 31 executes a predetermined API defined for each signal to receive various control requests from the ADK 2 and output vehicle states to the ADK 2. When the VCIB 31 receives a control request from the ADK 2, it outputs a control command corresponding to the control request to a system corresponding to the control command via the ECU 321. The VCIB 31 also acquires various information related to the vehicle state (state of the base vehicle 32) via the ECU 321, and outputs the acquired information to the ADK 2.

[0040] The VCIB31 includes a VCIB311 and a VCIB312. The VCIB311 and the VCIB312 basically have the same functions. However, between the VCIB311 and the VCIB312, some of the buses connected to the systems of the base vehicle 32 are different. Specifically, the VCIB311 is communicatively connected to the brake system 322A, the steering system 323A, the EPB system 324A, the P-lock system 324B, the propulsion system 324C, and the body system 326. The VCIB312 is communicatively connected to the brake system 322B, the steering system 323B, and the P-lock system 324B.

[0041] The ECU 321 integrates and controls the systems in the base vehicle 32 in cooperation with the ADK 2. The ECU 321 also transmits various information indicating the vehicle state to the vehicle server 7 via the DCM 327, and transmits various requests to the vehicle server 7. The ECU 321 also receives commands or notifications from the vehicle server 7 via the DCM 327.

[0042] Each of the brake systems 322A and 322B is configured to control a brake device (not shown) provided on each wheel of the base vehicle 32. The brake device includes, for example, a disk brake system that operates according to a hydraulic pressure adjusted by an actuator. The brake system 322A generates a braking command for the brake device according to a control request transmitted from the ADK2 via the VCIB311.

[0043] Each of the steering systems 323A and 323B is configured to control the steering angle of the steering wheels of the vehicle 1 using a steering device (not shown). The steering device includes, for example, an electric power steering (EPS) capable of adjusting the steering angle by an actuator. The steering system 323A generates a steering command for the steering device according to a control request transmitted from the ADK2 via the VCIB 311. The steering system 323B generates a steering command for the steering device according to a control request transmitted from the ADK2 via the VCIB 312.

[0044] The EPB system 324A controls an EPB (not shown) provided on at least one of the wheels in accordance with a control request transmitted from the ADK2 via the VCIB 311. The EPB fixes the wheel by, for example, operating a drum brake for a parking brake.

[0045] The P lock system 324B controls a P lock device (not shown) provided on the transmission in accordance with a control request transmitted from the ADK2 via the VCIB 311. The P lock device fixes the rotation of the output shaft of the transmission by engaging a parking lock pole with a lock gear provided and connected to a rotating element in the transmission. This fixes the wheels.

[0046] The propulsion system 324C switches the shift range of a shift device (not shown) in accordance with a control request transmitted from the ADK2 via the VCIB 311. The propulsion system 324C also controls the driving force from a driving source (such as a motor generator or an engine, not shown) in accordance with a control request from the ADK2.

[0047] The active safety system 325 detects an obstacle in front or behind the vehicle 1 using a group of sensors (camera, radar, sensor, etc.) not shown. The active safety system 325 determines whether or not there is a possibility that the vehicle 1 will collide with the obstacle based on the distance between the vehicle 1 and the obstacle and the moving direction of the vehicle 1. If the active safety system 325 determines that there is a possibility of a collision, it outputs a braking command to the brake system 322A to increase the braking force.

[0048] The body system 326 is configured to control components such as turn signals, a horn, and windshield wipers (none of which are shown) in accordance with, for example, the driving state or environment of the vehicle 1. The body system 326 controls each of the above components in accordance with a control request transmitted from the ADK2 via the VCIB31.

[0049] The DCM 327 is an in-vehicle communication module that is configured to enable two-way data communication between the ECU 321 and the vehicle server 7.

[0050] <Server hardware configuration> 3 is a block diagram showing a typical hardware configuration of the dealer server 5. The dealer server 5 includes a processor 51, a memory 52, a keyboard 53, a mouse 54, a display 55, and a communication interface (IF) 56. The memory 52 includes a read only memory (ROM) 521, a random access memory (RAM) 522, and a hard disk drive (HDD) 523. The processor 51, the memory 52, the keyboard 53, the mouse 54, the display 55, and the communication IF 56 are connected to each other via a bus.

[0051] The processor 51 controls the overall operation of the dealer server 5. The memory 52 stores an operating system and application programs executed by the processor 51. In particular, a maintenance schedule (see FIG. 8) is stored in the HDD 523 of the dealer server 5. The keyboard 53 and mouse 54 accept input from an operator of the dealer server 5. The display 55 displays various information to the operator. The communication IF 56 is configured to be capable of communicating with other servers (the ADK server 6 and the vehicle server 7).

[0052] Fig. 4 is a block diagram showing a typical hardware configuration of the ADK server 6. Fig. 5 is a block diagram showing a typical hardware configuration of the vehicle server 7. The hardware configurations of the ADK server 6 and the vehicle server 7 are basically the same as the hardware configuration of the dealer server 5, and therefore description thereof will not be repeated.

[0053] The HDD 623 of the ADK server 6 stores a database (see FIG. 6) of ADK abnormality information collected from the ADKs 2. The HDD 723 of the vehicle server 7 stores a database (see FIG. 7) of VP abnormality information collected from a large number of VPs 3. The HDD 723 also stores the above-mentioned user registration information.

[0054] <Database> 6 is a conceptual diagram showing the schematic configuration of a database relating to ADK anomaly information. The database has a data table 81. In the data table 81, for each identification number (ADK-ID) of a plurality of ADKs 2, the identification number (VP-ID) of the VP3 in which that ADK 2 is mounted and information relating to an anomaly that has occurred in that ADK 2 (ADK anomaly information) are associated. The ADK anomaly information is represented using a predefined anomaly code.

[0055] The abnormality code includes a section (such as a symbol or a numerical value) indicating the location of the abnormality. In this example, the abnormality code includes a section indicating which of the computer 21, the recognition sensor 22, the attitude sensor 23, the sensor cleaner 24, the HMI 25, and the communication module 26 (see FIG. 2) is the abnormal location. Although not shown in order to avoid cluttering the drawing, it is desirable for the abnormality code to include a section that specifies the abnormal location in more detail. For example, in a configuration in which the recognition sensor 22 includes a LIDAR and a camera (neither of which is shown), the abnormality code may include a section indicating which of the LIDAR and the camera is the abnormal location.

[0056] The abnormality code further includes a category according to the specific content of the abnormality. This category indicates, for example, a communication failure, a power supply abnormality, a drop in output voltage, etc. The ADK abnormality information may include the time of occurrence of the abnormality in addition to the category indicating the abnormality location and the category indicating the abnormality content.

[0057] The data table 81 is automatically updated. That is, when the ADK server 6 receives ADK abnormality information from an ADK 2, it updates the above two categories indicated in the ADK abnormality information. In addition, information about newly manufactured ADKs 2 is added to the data table 81, and information about discarded ADKs 2 is deleted from the data table 81.

[0058] 7 is a conceptual diagram showing the schematic configuration of a database for VP anomaly information. The database has a data table 82. In data table 82, for each identification number (VP-ID) of multiple VP3s, the identification number (ADK-ID) of the ADK2 mounted on that VP3 and information about anomalies that have occurred in that VP3 (VP anomaly information) are associated. Like the ADK anomaly information, the VP anomaly information is represented using a predefined anomaly code.

[0059] The abnormality code includes a category indicating the location of the abnormality. In this example, the abnormality code includes a category indicating which of the VCIB 31, the ECU 321, the brake system 322, the steering system 323, the power train system 324, the active safety system 325, the body system 326, and the DCM 27 (see FIG. 2) the abnormality location is. It is preferable that the abnormality code includes a category that specifies the abnormality location in more detail. The abnormality code further includes a category according to the specific content of the abnormality. The VP abnormality information may also include the time of abnormality occurrence. The data table 82 is also automatically updated.

[0060] <Maintenance Schedule> When some abnormality occurs in the ADK2 and / or VP3 and maintenance becomes necessary, the user brings the vehicle 1 to a dealer and requests maintenance. As described above, the dealer server 5 has a maintenance schedule for monitoring the ADK2 and VP3 scheduled for maintenance at the dealer.

[0061] FIG. 8 is a conceptual diagram of a maintenance schedule. An example will be described in which a dealer owns two pieces of equipment (listed as ADK-1 and ADK-2) capable of servicing ADK2, and two pieces of equipment (listed as VP-1 and VP-2) capable of servicing VP3. In the maintenance schedule 83, for each of the four pieces of equipment, whether it is "reserved" or "available" is shown for each one-hour time slot. "Reserved" means that a maintenance reservation has already been made. "Available" means that no maintenance reservation has been made at the present time, and a new maintenance reservation can be accepted.

[0062] During maintenance of the ADK2, the user may be unable to use the entire vehicle 1 including the VP3, which may cause inconvenience to the user. Therefore, it is desirable to reduce the inconvenience to the user caused by the maintenance of the ADK2 as much as possible. Therefore, in this embodiment, the maintenance of the ADK2 is divided into maintenance that requires the ADK2 to be removed from the VP3 and maintenance that does not require the ADK2 to be removed from the VP3. A specific example will be described below.

[0063] The computer 21 of the ADK2 is made redundant by including two processors 211, 212. Therefore, even if an abnormality occurs in one of the processors 211, 212, the computer 21 can output various commands for automatic operation to the VP3 using the other normal processor. Even so, it is desirable to immediately perform maintenance on the ADK2. In this maintenance, the ADK2 is removed from the VP3 in order to inspect, repair, or replace the processors 211, 212. When an abnormality occurs inside the ADK2 as in this example, maintenance is basically performed that requires removing the ADK2 from the VP3.

[0064] On the other hand, for example, dirt may adhere to the recognition sensor 22 (LIDAR, millimeter wave radar, camera, etc.) while the vehicle 1 is traveling. If the dirt cannot be removed using the sensor cleaner 24, it is desirable to immediately perform maintenance on the ADK2. However, in many cases, dirt adhered to the recognition sensor 22 can be removed without removing the ADK2 from the VP3. When an abnormality occurs in the appearance of the ADK2 as in this example, maintenance may be performed that does not require removing the ADK2 from the VP3.

[0065] For each abnormality code of the ADK2, it is determined in advance whether the maintenance to eliminate the abnormality corresponding to the abnormality code is maintenance that requires removing the ADK2 from the VP3 or maintenance that does not require removing the ADK2 from the VP3. Therefore, when the vehicle server 7 receives an abnormality code of the ADK2 together with an ADK maintenance request from the ADK server 6, it can determine whether or not the ADK2 needs to be removed based on the abnormality code of the ADK2. In this embodiment, when the maintenance that does not require removing the ADK2 from the VP3 can be performed, the vehicle server 7 proposes to the user to set a maintenance schedule that takes this into consideration.

[0066] 9 is a diagram for explaining a method for setting a maintenance schedule for performing maintenance that does not require removal of the ADK 2 from the VP 3. In a case where it is not necessary to remove the ADK 2 from the VP 3, in this embodiment, a continuous time period is set so that the maintenance of the ADK 2 and the maintenance of the VP 3 can be performed consecutively.

[0067] In the example shown in Fig. 9, for example, maintenance of VP3 can be performed at facility VP-2 in the time slot from 10:00 to 11:00, and maintenance of ADK2 can be performed at facility ADK-1 in the following time slot from 11:00 to 12:00. Alternatively, maintenance of ADK2 can be performed at facility ADK-1 in the time slot from 11:00 to 12:00, and maintenance of VP3 can be performed at facility VP-2 in the following time slot from 12:00 to 13:00.

[0068] In this manner, in this embodiment, the maintenance time zone of ADK2 and the maintenance time zone of VP3 are set consecutively. In this way, compared to the case where the maintenance time zone of ADK2 and the maintenance time zone of VP3 are set separately, the total maintenance time of ADK2 and VP3 is shortened by the amount of the absence of free time between the maintenance time zone of ADK2 and the maintenance time zone of VP3. For the user, the waiting time until the maintenance of ADK2 and VP3 is completed is shortened. Therefore, according to this embodiment, it is possible to reduce the disadvantage to the user associated with the maintenance of the vehicle 1 in which the ADK2 is mounted on the VP3.

[0069] When maintenance is performed that requires the ADK2 to be removed from the VP3, the dealer first removes the ADK2 from the VP3. The removed ADK2 is sent from the dealer to the ADK manufacturer, who then performs maintenance on it. The maintained ADK2 is then returned from the ADK manufacturer to the dealer. The dealer then reinstalls the ADK2 in the VP3. In this way, when the ADK2 needs to be removed from the VP3, the maintenance of the ADK2 and the maintenance of the VP3 are performed in different locations. Therefore, it is desirable for the vehicle server 7 to check the maintenance schedule of the dealer as well as the maintenance schedule of the ADK manufacturer, and then set the maintenance schedules of the ADK2 and VP3 so that the total maintenance time for the ADK2 and VP3 (the time until the vehicle 1 after maintenance is returned to the user) is minimized.

[0070] <User interface> User registration is performed when the vehicle 1 is sold, and the user's account and password are associated with the vehicle 1 (ADK2 and VP3) owned by the user. Here, it is assumed that user registration has already been completed and login (user authentication) for reserving the vehicle 1 has been successful. The following describes the GUI (Graphical User Interface) displayed on the user terminal 4 after login. First, the desired maintenance date is selected by the user.

[0071] 10 is a diagram showing an input screen for selecting a desired maintenance date. The input screen 91 includes a calendar 911 for selecting a desired maintenance date, and a button 912 for proceeding to the next input screen (a maintenance time slot selection screen).

[0072] The user selects the desired date (desired maintenance date) from among the dates (dates that are not grayed out) on calendar 911 that have available maintenance reservations. After selecting the desired maintenance date, the user operates button 912. This causes the desired maintenance date entered on input screen 91 to be sent to the vehicle server 7. The vehicle server 7 obtains the maintenance schedule (time periods during which the dealer can perform maintenance) for the user's desired maintenance date from the dealer server 5. The vehicle server 7 extracts consecutive time periods during the user's desired maintenance date when maintenance of ADK2 and maintenance of VP3 can be performed consecutively, as described in FIG. 9, and creates a screen that proposes one or more candidate maintenance time periods.

[0073] Fig. 11 is a diagram showing an input screen for selecting a maintenance time slot. The input screen 92 includes a display field 921 for displaying candidates for maintenance time slots, a button 922 for transitioning to a selection screen for maintenance time slots other than the candidates, a button 923 for returning to the previous input screen (selection screen for desired maintenance date) 91 (see Fig. 10), and a button 924 for proceeding to a confirmation screen.

[0074] In this example, candidates A to C of the maintenance time slot extracted by the vehicle server 7 are displayed. The user can select only one of the candidates A to C. In FIG. 11, candidate B is selected. If the desired maintenance time slot is not among the displayed candidates A to C, the user can select button 922. Then, a screen showing a list of maintenance time slots as shown in FIG. 9 is displayed, and the user can select the desired maintenance time slot while referring to the screen. The user can return to the previous input screen 91 as necessary by operating button 923. After selecting the desired maintenance time slot, the user operates button 924. As a result, the information input on the input screen 92 (such as the maintenance time slot selected from the candidates A to C) is transmitted to the vehicle server 7. The vehicle server 7 creates a confirmation screen for the maintenance reservation based on the maintenance date and maintenance time slot selected by the user.

[0075] 12 is a diagram showing a confirmation screen for a maintenance reservation. The confirmation screen 93 includes a display field 931 for displaying maintenance details, a button 932 for confirming the maintenance reservation, and a button 933 for returning to the input screen 91 (see FIG. 10).

[0076] The display field 931 includes information regarding, for example, the maintenance item, the maintenance date, the start time of the maintenance time slot, and the time required for the maintenance, for each of the ADK2 and VP3 (described as the vehicle body). The display field 931 may include a button 931A for displaying details of the maintenance item (an explanation of the contents of the abnormality code in an easy-to-understand manner for the user). When the user selects the button 932, the maintenance date and maintenance time slot selected by the user are transmitted from the vehicle server 7 to the dealer server 5. This confirms the maintenance reservation, and the maintenance schedule is updated in the dealer server 5. On the other hand, when the user selects the button 933, the input screen 91 is displayed again. In this case, the user can reselect the desired maintenance date.

[0077] <Processing sequence> 13 is a sequence diagram showing the flow of processing in the information processing system 100. In the figure, from left to right, the processing executed by the user terminal 4, the ADK server 6, the vehicle server 7, and the dealer server 5 is shown. Hereinafter, a sequence is abbreviated as "SQ." Although not shown, it is assumed that an abnormality requiring maintenance has also occurred in VP3.

[0078] In SQ1, the ADK server 6 sends an ADK maintenance request together with the ADK abnormality information to the vehicle server 7. The vehicle server 7 refers to the user registration information to identify the dealer server 5 operated by the dealer in charge of the vehicle 1. The vehicle server 7 then requests the identified dealer server 5 for the date on which the dealer can perform maintenance (maintenance available date) (SQ2). In response to the request from the vehicle server 7, the dealer server 5 transmits the maintenance available date (SQ3).

[0079] In SQ4, the vehicle server 7 queries the user terminal 4 for the date on which the user wishes to have the vehicle serviced (desired maintenance date) among the days on which the dealer can perform maintenance (see FIG. 10). The user terminal 4 accepts the user's operation to select the desired maintenance date (SQ5). The user terminal 4 transmits the desired maintenance date selected by the user to the vehicle server 7. The vehicle server 7 requests from the dealer server 5 the time period during which the dealer can perform maintenance on the user's desired maintenance date (available maintenance time period) (SQ6). The dealer server 5 transmits the available maintenance time period in response to the request from the vehicle server 7 (SQ7).

[0080] In SQ8, the vehicle server 7 extracts consecutive time slots during which the maintenance of ADK2 and the maintenance of VP3 can be performed consecutively from the dealer's available maintenance time slots, and proposes the extracted time slots to the user terminal 4 (see FIG. 11). The user terminal 4 accepts a user operation to select a maintenance time slot (SQ9). The user terminal 4 transmits the maintenance time slot selected by the user to the vehicle server 7.

[0081] Although not shown due to space limitations, after that, when the user makes a final confirmation (see FIG. 11), the vehicle server 7 sends a notification to the dealer server 5 to confirm the maintenance reservation (SQ10). The dealer server 5 confirms the maintenance reservation and updates the maintenance schedule in accordance with the notification from the vehicle server 7 (SQ11). The vehicle server 7 also notifies the ADK server 6 of the maintenance date and maintenance time slot for ADK2 (SQ12). This allows the ADK server 6 to recognize that the ADK maintenance request has been satisfied. The ADK server 6 stores the maintenance date and maintenance time slot for ADK2 in a database (not shown) (SQ13).

[0082] As described above, in this embodiment, when an abnormality occurs in both ADK2 and VP3, and ADK2 can be serviced without removing ADK2 from VP3, a time period during which ADK2 and VP3 can be serviced consecutively is proposed to the user. If the user accepts the proposal, there is no free time between the maintenance of ADK2 and the maintenance of VP3, and the user's waiting time (time during which vehicle 1 cannot be used) is reduced. Therefore, according to this embodiment, it is possible to reduce the inconvenience to the user associated with the maintenance of vehicle 1 in which ADK2 is mounted on VP3.

[0083] The embodiments disclosed herein should be considered to be illustrative and not restrictive in all respects. The 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]

[0084] 100 Information processing system, 1 Vehicle, 2 Autonomous driving kit (ADK), 21 Computer, 211, 212 Processor, 22 Recognition sensor, 23 Attitude sensor, 24 Sensor cleaner, 25 HMI, 26 Communication module, 3 Vehicle platform (VP), 31, 311, 312 Vehicle control interface box (VCIB), 32 Base vehicle, 321 ECU, 322, 322A, 322B Brake system, 323, 323A, 323B Steering system, 324 Power train system, 324A Electric parking brake (EPB) system, 324B Parking lock system, 324C Propulsion system, 325 Active safety system, 326 Body system, 327 DCM, 4 User terminal, 5 Dealer server, 51 Processor, 52 Memory, 521 ROM, 522 RAM, 533 HDD, 53 keyboard, 54 mouse, 55 display, 56 communication IF, 6 ADK server, 61 processor, 62 memory, 621 ROM, 622 RAM, 633 HDD, 63 keyboard, 64 mouse, 65 display, 66 communication IF, 7 vehicle server, 71 processor, 72 memory, 721 ROM, 722 RAM, 733 HDD, 73 keyboard, 74 mouse, 75 display, 76 communication IF.

Claims

1. A server that sets a maintenance schedule for a vehicle mounted on a vehicle platform by an autonomous driving system, A processor; A memory in which a program executable by the processor is stored, The processor, when an abnormality in the autonomous driving system and an abnormality in the vehicle platform occur, is a specified abnormality that allows the autonomous driving system to be maintained without removing the autonomous driving system from the vehicle platform, and sets the maintenance schedule to a time period when maintenance of the autonomous driving system and maintenance of the vehicle platform can be performed consecutively.

2. The server according to claim 1 , wherein the predetermined abnormality includes an abnormality that can be serviced from the outside of the autonomous driving system.

3. The autonomous driving system includes a sensor for recognizing an environment of the vehicle; The server according to claim 2 , wherein the abnormality that can be serviced from the outside includes an abnormality caused by dirt adhering to the sensor.

4. The processor, Extracting one or more candidate time slots during which maintenance of the automated driving system and maintenance of the vehicle platform can be performed consecutively from among available time slots in the maintenance schedule; Proposing the one or more extracted candidate time slots to a user terminal; A server according to any one of claims 1 to 3, which allocates a selected time period to the maintenance of the autonomous driving system and the vehicle platform when any one of the one or more candidate time periods is selected by an operation on the user terminal.

Images