Vehicle control system and vehicle control method

Abstract

This system allows users to deactivate the immobilizer without having to wait near the vehicle when they delegate vehicle operation control to the management system within a designated area. [Solution] The vehicle control system comprises a management system for managing the vehicle and a control device mounted on the vehicle. The management system responds to a handover start request from a user terminal and starts a handover process to transfer the vehicle's operation rights from the user to the management system. Based on the result of a first communication between the control device and the vehicle's key, the vehicle control system confirms that the key is within a predetermined range from the vehicle when the handover start request is issued. If the presence of the key is confirmed by this key presence confirmation process, the control device, provided that it is within a predetermined period since the key's presence was confirmed, releases the vehicle's immobilizer's restriction on starting the driving system in response to a request from the management system to start the vehicle's driving system.

Description

Technical Field

[0001] The present disclosure relates to a technology for controlling a vehicle that operates according to a remote instruction in a predetermined area.

Background Art

[0002] Patent Document 1 discloses a vehicle monitoring device that monitors a vehicle within a vehicle parking position. The vehicle monitoring device switches between a vehicle position notification mode and an anti-theft mode in response to a mode switching instruction.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] When a user entrusts the operation authority of a vehicle to a management system in a predetermined area (e.g., a parking lot), the user operates a user terminal to transmit a handover start request to the management system. After that, the user can leave the vehicle. On the other hand, the management system needs to complete predetermined processes such as processing for identifying (recognizing) the vehicle to be remotely operated between starting the handover process according to the handover start request and transmitting a start request for the vehicle's driving system to the vehicle. If the execution of the predetermined process takes time and the user having the vehicle key leaves the vehicle before transmitting the start request for the driving system, the management system cannot cause the vehicle to release the immobilizer necessary for starting the driving system.

[0005] This disclosure is made in view of the above-mentioned issues and aims to provide a technology that enables the immobilizer to be deactivated without requiring the user to wait near the vehicle when the user entrusts vehicle operation rights to the management system in a predetermined area. [Means for solving the problem]

[0006] The vehicle control system described herein controls a vehicle operating in a predetermined area according to remote instructions. The vehicle control system comprises a management system and a control device. The management system manages the vehicle. The control device is mounted on the vehicle and communicates with the management system. In response to a handover start request from a user terminal operated by the vehicle's user, the management system initiates a handover process to transfer vehicle operation rights from the user to the management system. Based on the result of a first communication between the control device and the vehicle's key, the vehicle control system performs a key existence verification process to confirm that the key is within a predetermined range from the vehicle when the handover start request is issued. If the key's existence is confirmed by the key existence verification process, the control device, provided that it is within a predetermined period since the key's existence was confirmed, releases the vehicle's immobilizer's restriction on starting the vehicle's driving system in response to a request from the management system to start the vehicle's driving system.

[0007] The vehicle control method relating to this disclosure is a method for controlling a vehicle operating in a predetermined area according to remote instructions, and is performed by a computer. The vehicle control method includes: initiating a handover process to transfer vehicle operation rights from the user to a management system that manages the vehicle in response to a handover start request from a user terminal operated by the vehicle's user; performing a key existence confirmation process to confirm that the key is within a predetermined range from the vehicle at the time the handover start request is made, based on the result of a first communication between a control device installed in the vehicle and the vehicle's key; and, if the existence of the key is confirmed by the key existence confirmation process, releasing the vehicle's immobilizer's prohibition on starting the driving system in response to a request from the management system to start the vehicle's driving system, provided that it is within a predetermined period since the key's existence was confirmed. [Effects of the Invention]

[0008] According to this disclosure, when a handover start request is issued, the immobilizer's restriction on starting the vehicle's driving system is lifted in response to a start request from the management system, upon confirmation that the vehicle key is within a predetermined range of the vehicle, even if the user is not near the vehicle. This allows the management system to start the driving system without requiring the user to wait near the vehicle after the handover process is complete. [Brief explanation of the drawing]

[0009] [Figure 1] This is a conceptual diagram illustrating the overview of a vehicle control system according to an embodiment. [Figure 2] Figure 1 is a block diagram showing an example configuration of the management system. [Figure 3] This block diagram shows an example of the vehicle system configuration shown in Figure 1. [Figure 4] This flowchart shows an example of the processing flow related to the deactivation of the immobilizer using key presence verification according to the embodiment. [Figure 5]This flowchart shows another example of the processing flow related to the disabling of the immobilizer using key presence verification according to the embodiment. [Figure 6] This flowchart shows the first example of the key existence verification process in step S104. [Figure 7] This flowchart shows a second example of the key existence verification process in step S104. [Figure 8] This flowchart shows an example of the flow of additional processing during parking, which is included in the process related to disabling the immobilizer using key presence confirmation according to the embodiment. [Modes for carrying out the invention]

[0010] Embodiments of this disclosure will be described with reference to the attached drawings.

[0011] 1. Overview of the Vehicle Control System Figure 1 is a conceptual diagram illustrating the overview of the vehicle control system 100 according to this embodiment. The vehicle control system 100 controls vehicle 1. Vehicle 1 is configured to operate in a predetermined area according to remote instruction INS. The predetermined area is, for example, an area in which vehicle 1 can drive automatically, and vehicle 1 drives automatically in the predetermined area according to remote instruction INS. The vehicle control system 100 includes a management system 10 and a vehicle system 20 mounted on vehicle 1. The management system 10 manages vehicle 1. The management of vehicle 1 by the management system 10 includes generating remote instruction INS. More specifically, the management system 10 manages the automatic driving (unmanned driving) of vehicle 1 within the predetermined area.

[0012] 1-1. Automatic Valet Parking (AVP) In the example shown in Figure 1, the designated area is parking lot 2. In this example, the vehicle control system 100 corresponds to an automated valet parking system that performs AVP (Automatic Valet Parking) for vehicle 1 in parking lot 2. However, the designated area is not limited to parking lot 2; for example, it could be a city such as a smart city or a part thereof. The following explanation will use parking lot 2 as an example of a designated area.

[0013] Vehicle 1 is configured to run AVP in parking lot 2. Vehicle 1 can drive automatically without user operation, at least within parking lot 2. More specifically, the automatic driving of vehicle 1 within parking lot 2 is controlled, for example, by a management system 10 that utilizes infrastructure sensors 13. Alternatively, the automatic driving may be controlled, for example, by cooperation between the management system 10 and the vehicle system 20. Vehicle 1 may also be an autonomous vehicle capable of driving automatically outside of parking lot 2.

[0014] Parking area 2 includes a drop-off area 3, a pick-up area 4, and a parking area 5. When a vehicle 1 enters parking area 2, it stops at a stopping position (drop-off space) 6 provided in the drop-off area 3, where the user alights from the vehicle 1. On the other hand, when a vehicle 1 leaves parking area 2, it stops in the pick-up area 4, where the user boards the vehicle 1. The drop-off area 3 can also be called the entry area, and the pick-up area 4 can be called the exit area. The drop-off area 3 and the pick-up area 4 may be provided separately as shown in Figure 1, or they may be provided as a single pick-up / drop-off area without distinction between pick-up and drop-off. Parking area 5 includes a passageway 7 and multiple parking spaces 8. The passageway 7 is the area through which the vehicle 1 travels. The parking spaces 8 are the spaces in which the vehicle 1 parks.

[0015] The management system 10 manages the AVP of vehicle 1 in parking lot 2. The management system 10 includes, for example, a local management device 11 and a management server 12 in the cloud.

[0016] The local management device 11 is installed for each parking lot 2. The local management device 11 executes the following processes, for example. That is, the local management device 11 grasps the situation of the parking lot 2 (e.g., the position and state of each vehicle 1 in the parking lot 2) using the infrared sensor 13. The local management device 11 assigns a parking space 8 to the vehicle 1. The local management device 11 generates a remote instruction INS, communicates with the vehicle 1, and transmits the generated remote instruction INS to the vehicle 1.

[0017] The management server 12 supervises the local management devices 11 of multiple parking lots 2. The management server 12 may include three servers OB, VB, and UB as an example. The server OB is provided for each parking lot 2. The server OB manages the parking lot 2 (e.g., reservation of the parking space 8, entry and exit of the vehicle 1), and the driving control authority of the vehicle 1. Also, the server OB communicates with the corresponding local management device 11, collects various information, and provides various information. The server VB manages the remote operation authority of the vehicle 1 (e.g., power operation authority). Also, the server VB communicates with the vehicle 1, collects various vehicle management information (e.g., information indicating the state of the vehicle 1, identification information of the vehicle 1 (vehicle ID)), and provides various information (e.g., progress status of AVP). The server UB manages the users of the automated valet parking service (AVP service) (including user authentication), and reservation management of the AVP service by the users. The server UB communicates with the user terminal 30 operated by the user of the AVP service. The user terminal 30 is, for example, a terminal (e.g., smartphone) possessed by the user. The membership information of the user is registered in the server UB in advance. Also, the server UB communicates with each of the server OB and the server VB, and transmits and receives various information between each of the server OB and the server VB.

[0018] Hereinafter, an example of the process when a certain user X uses the AVP service will be described.

[0019] First, user X makes a reservation for AVP. For example, user X operates user terminal 30 to input information such as user X's ID information, desired parking lot 2, desired usage date, and desired usage time. The user terminal 30 transmits reservation information including the input information to the management system 10 (server UB). The management system 10 performs reservation processing based on the reservation information and transmits a reservation completion notice to the user terminal 30. In addition, the management system 10 transmits authentication information corresponding to the reservation information to the user terminal 30. The user terminal 30 receives the authentication information and holds the received authentication information.

[0020] The entry (check-in) of vehicle 1 into parking lot 2 is as follows. As illustrated in FIG. 1, vehicle 1 carrying user X arrives at the drop-off area 3 of parking lot 2 and stops at the stop position 6. In the drop-off area 3, user X (and other passengers if any) gets off vehicle 1.

[0021] In order to start the automatic driving of vehicle 1 (hereinafter simply referred to as "AVP driving") based on the remote instruction INS from the management system 10 in AVP, it is necessary to transfer the operation authority of vehicle 1 from user X to the management system 10. For this transfer of operation authority, user X operates user terminal 30 to transmit a handover start request to the management system 10 (server UB). More specifically, after the arrival of vehicle 1 at the drop-off area 3, it is basically assumed that user X gets off vehicle 1 and then makes a handover start request. However, the handover start request can be made by user X before getting off vehicle 1. The handover start request is transmitted, for example, together with user X's authentication information. Note that the user terminal 30 used for the user X to make a handover start request before getting off vehicle 1 is not limited to a mobile terminal such as a smartphone owned by user X, and may also be an HMI (Human Machine Interface) device installed in vehicle 1.

[0022] In response to a handover start request sent from user terminal 30, the management system 10 (server UB) authenticates user X. Once authentication is complete, the management system 10 (local management device 11) starts a handover process (authorization transfer process) to transfer the operating authority of vehicle 1 from user X to the management system 10.

[0023] The handover process includes, for example, a process for establishing wireless communication between the management system 10 and vehicle 1 (vehicle system 20), and a process for identifying vehicle 1 as the target vehicle for this AVP (vehicle identification process). Target vehicle identification (authentication) is necessary to confirm that vehicle 1, which is seeking to receive the AVP service, is the vehicle 1 (target vehicle) of the legitimate user X. The vehicle identification process may, for example, be performed using a predetermined action of vehicle 1 (e.g., blinking of vehicle 1's lights). If vehicle 1 is a legitimate target vehicle, it is expected that the vehicle will perform the predetermined action in accordance with instructions from the management system 10. After such instructions are given, the management system 10 uses the infrastructure sensor 13 to recognize the action performed by vehicle 1. If the recognized action matches the expected action, the management system 10 identifies vehicle 1, which performed the recognized action, as the target vehicle.

[0024] Once the handover process is complete, the control authority for vehicle 1 is transferred from user X to the management system 10. The management system 10 (local management device 11) performs parking processing for vehicle 1. During parking processing, the management system 10 communicates with vehicle 1 and sends a remote instruction INS (start request) requesting the vehicle 1's driving system 23 to be activated (powered on). Provided that the immobilizer, as described later, can be deactivated, vehicle 1 automatically activates the driving system 23 according to the received remote instruction INS. The management system 10 also refers to the usage status of parking lot 2, assigns an available parking space 8 to vehicle 1, and then generates a target route for vehicle 1 from the drop-off area 3 to the assigned parking space 8. The management system 10 then communicates with vehicle 1 and sends a remote instruction INS to vehicle 1, along with the target route information, requesting that the vehicle perform AVP driving towards parking space 8 along the generated target route.

[0025] Vehicle 1 performs AVP driving towards its assigned parking space 8 according to the target route received from the management system 10, and automatically parks in the assigned parking space 8 (parking complete). Once parking is complete, vehicle 1 notifies the management system 10 of the completion of parking. Alternatively, the management system 10 may detect that vehicle 1 has completed parking using the infrastructure sensor 13 installed in the parking lot 2. After vehicle 1 has completed parking, the management system 10 (local management device 11) communicates with vehicle 1 and sends a remote instruction INS requesting the power off of the driving system 23. Vehicle 1 automatically turns off its power according to the received remote instruction INS. The management system 10 (server OB) also maintains information about the parking space 8 where vehicle 1 is parked, associating it with user X. The management system 10 (local management device 11) may cause vehicle 1 to perform AVP driving to move vehicle 1 to another parking space 8 while it is parked.

[0026] The process for vehicle 1 to leave parking lot 2 (checkout) is as follows: User X operates user terminal 30 to send a checkout request to management system 10 (server UB) to request the vehicle 1 to leave the parking lot. The checkout request includes user X's authentication information. In response to the checkout request, management system 10 (server UB) authenticates user X. Once authentication is complete, management system 10 (local management device 11) performs the checkout process for vehicle 1.

[0027] During the vehicle departure process, the management system 10 communicates with vehicle 1 and executes a remote instruction INS (start request) requesting vehicle 1 to activate (power on) its driving system 23. Provided that the immobilizer can be deactivated, vehicle 1 automatically activates its driving system 23 according to the received remote instruction INS. The management system 10 also refers to the usage status of parking lot 2 and assigns vehicle 1 an available passenger space 9 in passenger area 4, and then generates a target route for vehicle 1 from its parking space 8 to the assigned passenger space 9. The management system 10 then communicates with vehicle 1 and sends a remote instruction INS to vehicle 1, along with the target route information, requesting that it perform an AVP drive towards passenger space 9 along the generated target route.

[0028] Vehicle 1 travels according to the received target route towards its assigned passenger slot 9 using the AVP system. When Vehicle 1 arrives at the passenger area 4 and automatically stops at its assigned passenger slot 9, Vehicle 1 notifies the management system 10 of its arrival at the passenger area 4. Alternatively, the management system 10 may detect the arrival of Vehicle 1 using the infrastructure sensor 13 installed in the passenger area 4.

[0029] After vehicle 1 arrives at boarding area 4, user X sends a handback start request to management system 10 (server UB) to transfer (return) control of vehicle 1 from management system 10 to user X. In response to the handback start request sent from user terminal 30, management system 10 (server UB) authenticates user X. Once authentication is complete, management system 10 (local management device 11) starts the handback process. When the handback process is complete, user X (and any other passengers) board vehicle 1. Vehicle 1 departs for its next destination and exits parking lot 2 (exit complete).

[0030] 2. Example System Configuration As described above, the vehicle control system 100 includes the management system 10 and the vehicle system 20.

[0031] 2-1. Management System Figure 2 is a block diagram showing an example configuration of the management system 10 shown in Figure 1. The management system 10 includes a local management device 11, a management server 12 on the cloud, and one or more infrastructure sensors 13 (hereinafter simply referred to as infrastructure sensors 13). The infrastructure sensors 13 are installed in various locations in the parking lot 2, as shown in Figure 1. The infrastructure sensors 13 include, for example, infrastructure cameras and recognize the conditions of the parking lot 2, including the drop-off area 3 and the pick-up area 4. The information acquired by the infrastructure sensors 13 is transmitted to the local management device 11.

[0032] The local management device 11 includes a communication interface (communication I / F) 111, one or more processors 112 (hereinafter simply referred to as processor 112), and one or more storage devices 113 (hereinafter simply referred to as storage devices 113).

[0033] The communication interface 111 communicates with vehicle 1 (vehicle system 20), management server 12 (server OB), and infrastructure sensor 13 via a communication network.

[0034] The processor 112 performs various processes. Examples of the processor 112 include general-purpose processors, application-specific processors, CPUs (Central Processing Units), GPUs (Graphics Processing Units), ASICs (Application Specific Integrated Circuits), FPGAs (Field-Programmable Gate Arrays), integrated circuits, conventional circuits, and / or combinations thereof. The processor 112 can also be called circuitry or processing circuitry. Circuitry is hardware programmed to realize the described functions, or hardware that performs those functions. The storage device 113 stores various information. Examples of storage devices 113 include volatile memory, non-volatile memory, HDDs (Hard Disk Drives), SSDs (Solid State Drives), etc.

[0035] The functions of the local management device 11 may be realized through the cooperation of a processor 112 that executes a computer program and a storage device 113. The computer program is stored in the storage device 113. Alternatively, the computer program may be recorded on a computer-readable recording medium or provided via a network.

[0036] The management server 12 (more specifically, each of the three servers OB, VB, and UB) includes a communication interface 121, one or more processors 122 (hereinafter simply referred to as processor 122), and one or more storage devices 123 (hereinafter simply referred to as storage devices 123).

[0037] The communication interface 121 communicates with the local management device 11, the vehicle 1 (vehicle system 20), and the user terminal 30 via the communication network.

[0038] The configuration example of processor 122 is the same as that of processor 112 described above. Similarly, the configuration example of storage device 123 is the same as that of storage device 113 described above. For example, the storage device 123 of server OB stores information for a predetermined area (e.g., parking lot 2) (e.g., map information for parking lot 2, entry and exit time information for parking lot 2). The storage device 123 of server VB stores the vehicle management information described above. The storage device 123 of server UB stores user information (e.g., identification information for each user (user ID), service reservation information). The functions of the management server 12 (e.g., servers OB, VB, and UB, respectively) may be realized through the cooperation of the processor 122, which executes the computer program, and the storage device 123. The computer program is stored in the storage device 123. Alternatively, the computer program may be recorded on a computer-readable recording medium or provided via a network.

[0039] 2-2. Vehicle System Figure 3 is a block diagram showing an example configuration of the vehicle system 20 shown in Figure 1. The vehicle system 20 is mounted on the vehicle 1 and includes a control device 21, sensors 22, and a driving system 23.

[0040] The control device 21 controls the vehicle 1 according to various remote instruction INS. The control device 21 includes a communication I / F 211, one or more processors 212 (hereinafter simply referred to as processor 212), and one or more storage devices 213 (hereinafter simply referred to as storage devices 213).

[0041] The communication interface 211 communicates with the management system 10 (more specifically, the local management device 11 and the management server 12 (server VB)) via a communication network. The communication interface 211 also communicates with the vehicle 1's key 31 in the communication Ckey (first communication) described later.

[0042] The configuration example of processor 212 is the same as that of processor 112 described above. Similarly, the configuration example of storage device 213 is the same as that of storage device 113 described above. The functions of the control device 21 may be realized through the cooperation of processor 212, which executes the computer program, and storage device 213. The computer program is stored in storage device 213. Alternatively, the computer program may be recorded on a computer-readable recording medium or provided via a network.

[0043] The vehicle system 20 functions as an immobilizer to prevent unauthorized activation of the driving system 23. For example, the control device 21 has this function. Specifically, the key 31 held by user X has a built-in transponder. The transponder includes a communication circuit that communicates with the vehicle 1 (control device 21), a processor, and a storage device that stores an authentication code unique to the key 31. This authentication code is also stored in the storage device 213 of the control device 21. Communication between the vehicle system 20 (control device 21) and the key 31 is via short-range wireless communication (e.g., UWB (Ultra Wideband), Bluetooth (registered trademark), NFC (Near Field Communication)).

[0044] When an authentication code is received from key 31, the control device 21 (processor 212) compares the received authentication code from key 31 with the authentication code stored in the storage device 213. If these authentication codes match, the control device 21 permits the activation of the driving system 23. In other words, the control device 21 releases the immobilizer's restriction on activating the driving system 23.

[0045] For example, key 31 is a smart key that has the immobilizer function described above and allows user X to remotely activate the driving system 23 by operating key 31 within a distance range where communication Ckey with vehicle 1 (control device 21) is possible. Alternatively, key 31 may be a digital key. Specifically, user terminal 30 (e.g., smartphone) may store key information for key 31 to function as a digital key for vehicle 1. Furthermore, user terminal 30 may be configured to be usable by user X as a digital key in place of key 31 without requiring a physical key 31.

[0046] Sensors 22 include recognition sensors, vehicle status sensors, position sensors, etc. Recognition sensors recognize (detect) the surrounding conditions of vehicle 1. Examples of recognition sensors include cameras, LIDAR (Laser Imaging Detection and Ranging), radar, etc. Vehicle status sensors detect the state of vehicle 1. Examples of vehicle status sensors include speed sensors, acceleration sensors, yaw rate sensors, steering angle sensors, etc. Position sensors detect the position and orientation of vehicle 1. Examples of position sensors include GNSS (Global Navigation Satellite System) sensors. Sensors 22 may also include sensors for detecting the locking / unlocking of the doors of vehicle 1. Furthermore, sensors 22 may include sensors for detecting a person boarding vehicle 1 (e.g., seating sensors).

[0047] The driving system 23 is a system for operating the vehicle 1. The driving system 23 is, for example, an electric drive system and includes an electric motor for driving the vehicle 1, a battery for supplying power to the electric motor, and a controller. The driving system 23 may include an internal combustion engine together with, or instead of, the electric motor for driving the vehicle 1.

[0048] 3. Disabling the immobilizer using key presence verification. When user X entrusts the management system 10 with the operation rights of vehicle 1 in a designated area (e.g., parking lot 2), user X operates the user terminal 30 as described above to send a handover start request to the management system 10. After that, user X can leave vehicle 1. On the other hand, the management system 10 needs to complete predetermined processes such as vehicle identification processing between the time it starts the handover process in accordance with the handover start request and the time it sends a request to vehicle 1 to start the vehicle's driving system 23. If the execution of these predetermined processes takes time and user X, who has the key 31 for vehicle 1, leaves vehicle 1 before the request to start the driving system 23 is sent, the management system 10 will be unable to verify the authentication code with the key 31. In other words, the management system 10 will be unable to have vehicle 1 deactivate the immobilizer, which is necessary to start the driving system 23.

[0049] Therefore, in this embodiment, when user X entrusts the operation authority of vehicle 1 to the management system 10 in a predetermined area (e.g., when vehicle 1 is parked in a predetermined area such as parking lot 2), the vehicle control system 100 executes a "key existence confirmation process". The key existence confirmation process is a process that confirms that key 31 is within a predetermined range R from vehicle 1 when a handover start request is issued from the user terminal 30, based on the result of the communication Ckey (first communication) between the control device 21 of vehicle 1 and the key 31 of vehicle 1 (communication result Rcom). The key 31 to be confirmed by the key existence confirmation process includes a digital key using the user terminal 30.

[0050] Then, if the existence of key 31 is confirmed by the key existence confirmation process, the control device 21, provided that it is within a predetermined period T since the existence of key 31 was confirmed, releases the immobilizer's restriction on starting the vehicle 1's driving system 23 in response to a request from the management system 10 (local management device 11) to start the vehicle 1's driving system 23.

[0051] 3-1. Processing Flow Figure 4 is a flowchart showing an example of the processing flow related to the deactivation of the immobilizer using key presence confirmation according to this embodiment. The processing in this flowchart starts, for example, when vehicle 1 arrives at the drop-off area 3. This processing is carried out in cooperation with the management system 10 (mainly the local management device 11) and the control device 21.

[0052] In step S100, the local management device 11 communicates with server UB via server OB and determines whether or not it has received a handover start request from user terminal 30. If a handover start request is received (step S100; Yes), the process proceeds to step S102.

[0053] In step S102, the local management device 11 starts the handover process described above. Then, in step S104, in conjunction with the handover start request, a "key existence confirmation process" is performed to confirm that the key 31 is within a predetermined range R from the vehicle 1. As will be described later with reference to Figure 6, the key existence confirmation process is performed, for example, by the control device 21. Alternatively, as will be described later with reference to Figure 7, the key existence confirmation process may be performed in cooperation with the control device 21 and the management system 10.

[0054] In addition, as mentioned above, the handover start request can be made not only after user X has exited vehicle 1, but also before. Therefore, even if user X, who possesses key 31, is still inside vehicle 1, the key existence verification process may still be performed to confirm the existence of key 31.

[0055] As will be described in detail later, the confirmation result Rcon of the existence of key 31 by the key existence confirmation process is stored in the storage device 213, 113, or 123. In step S106, following step S104, the local management device 11 acquires the confirmation result Rcon that has been stored in this manner. The confirmation result Rcon is information indicating whether or not key 31 is within a predetermined range R from vehicle 1 when a handover start request is issued. Based on the acquired confirmation result Rcon, the local management device 11 determines whether or not the existence of key 31 has been confirmed. If the existence of key 31 is not confirmed as a result (step S106; No), the process proceeds to step S108.

[0056] In step S108, the local management device 11 sends a notification to the user terminal 30 via servers OB and UB to confirm the location of key 31 to user X. This notification includes, for example, a message requesting user X to return to vehicle 1 with key 31. The process then returns to step S104. For example, if user X returns to vehicle 1 in accordance with the above notification, the determination result in step S106 becomes Yes.

[0057] On the other hand, if the presence of key 31 is confirmed (step S106; Yes), the process proceeds to step S110. In step S110, the control device 21 enables the function to deactivate the vehicle 1's immobilizer in response to a request from the management system 10. For example, the control device 21 turns on a flag indicating that the deactivation is enabled. In addition, the deactivation of the vehicle 1's immobilizer in response to a request from the management system 10 is normally disabled, and the flowchart shown in Figure 5 starts with the deactivation disabled.

[0058] In step S112, following step S110, the local management device 11 determines whether the handover process is complete. If the handover process is complete (step S112; Yes), the process proceeds to step S114.

[0059] In step S114, the local management device 11 sends a request to the vehicle 1 (control device 21) to start the driving system 23. That is, the local management device 11 starts the above-mentioned parking process.

[0060] In step S116, following step S114, the control device 21 receives a request from the management system 10 to activate the driving system 23. The control device 21 then releases the immobilizer's restriction on activating the driving system 23 in response to the received activation request and activates the driving system 23. After that, the vehicle 1 performs AVP driving towards the assigned parking space 8.

[0061] In step S118, following step S116, the local management device 11 determines whether the receiving process has been completed. If the receiving process is completed (step S118; Yes), the process proceeds to step S120.

[0062] In step S120, the local management device 11 communicates with server UB via server OB to determine whether it has received a request from user terminal 30 to release the parked vehicle 1. If a release request is received (step S120; Yes), the process proceeds to step S122.

[0063] In step S122, the local management device 11 starts the dispatch process described above in response to the received dispatch request. As a result, vehicle 1 performs AVP travel towards boarding area 4. Next, in step S124, the local management device 11 determines whether vehicle 1 has arrived at boarding area 4 (more specifically, the assigned boarding slot 9). If vehicle 1 has arrived at boarding area 4 (step S124; Yes), the process proceeds to step S126.

[0064] In step S126, the local management device 11 communicates with server UB via server OB and determines whether or not it has received a handback start request from user terminal 30. If a handback start request is received (step S126; Yes), the process proceeds to step S128.

[0065] In step S128, the local management device 11 starts the handback process described above in response to the received handback start request. The handback process is included in the outbound process. Next, in step S130, the local management device 11 determines whether the handback process has been completed. If the handback process is completed (step S130; Yes), the process proceeds to step S132.

[0066] In step S132, the control device 21 disables the function to deactivate the vehicle 1's immobilizer in response to a request from the management system 10. For example, the control device 21 turns off a flag indicating that the deactivation of the immobilizer is enabled. The process then proceeds to step S134.

[0067] Furthermore, the confirmation result Rcon regarding the existence of key 31, obtained through the key existence confirmation process, is stored on the vehicle 1 side (storage device 213 of the control device 21; see Figure 6 below) or on the management system 10 side (storage device 123 of server OB or VB or storage device 113 of local management device 11; see Figure 7 below). If the confirmation result Rcon is stored in storage device 213, in step S134 (i.e., upon the end of the predetermined period T), the control device 21 deletes the confirmation result Rcon from storage device 213. Similarly, if the confirmation result Rcon is stored in storage device 123 or 113, in step S134 (i.e., upon the end of the predetermined period T), the management system 10 deletes the confirmation result Rcon from storage device 123 or 113. More specifically, the local management device 11 sends an instruction to server OB or VB to delete the confirmation result Rcon, and server OB or VB deletes the confirmation result Rcon from storage device 123. Alternatively, the local management device 11 deletes the confirmation result Rcon from the storage device 113. By deleting the confirmation result Rcon at the end of a predetermined period T, that is, by limiting the opportunity to use the confirmation result Rcon for the purpose of disabling the immobilizer to the execution of a single AVP service, it becomes possible to provide an AVP service that is highly convenient for user X while giving high consideration to the security of vehicle 1.

[0068] To add to that, the departure process is completed when the handbag processing is finished. Then, when user X gets into vehicle 1 and vehicle 1 leaves parking lot 2, the departure of vehicle 1 itself is completed.

[0069] 3-1-1. Predetermined period T As already explained, the control device 21, on the condition that it is within a predetermined period T since the presence of the key 31 was confirmed, releases the immobilizer's restriction on starting the driving system 23 in response to a startup request.

[0070] 3-1-1-1. Example 1 In the example process shown in Figure 4, the predetermined period T ends when the handover period in which the operating authority of vehicle 1 is transferred from user X to management system 10 ends, that is, when the handback process is completed (step S130; Yes).

[0071] 3-1-1-2. Second Example Figure 5 is a flowchart showing another example of the processing flow related to the disabling of the immobilizer using key presence confirmation according to this embodiment. The processing in this flowchart differs from the processing in the flowchart shown in Figure 4 in the timing of disabling the immobilizer disabling function when vehicle 1 leaves the depot (in other words, the end of the predetermined period T).

[0072] Specifically, in Figure 5, the local management device 11 disables the function to deactivate the immobilizer of vehicle 1 in response to a request from the management system 10 when vehicle 1 arrives at the boarding area 4 (step S126; Yes) (step S200). In other words, in the example shown in Figure 5, the predetermined period T ends when vehicle 1 arrives at the boarding area 4 (more specifically, boarding slot 9) for departure from a predetermined area (e.g., parking lot 2).

[0073] In addition, in Figure 5, in step S202 following step S200 (i.e., upon completion of the predetermined period T), the control device 21 (or management system 10) deletes the confirmation result Rcon from the storage device 213 (or 123 or 113).

[0074] Alternatively, instead of the second example shown in Figure 5, the timing for disabling the immobilizer release function when vehicle 1 exits the parking space may be when the driving system 23 for moving vehicle 1 from parking space 8 to passenger space 9 has finished activating.

[0075] 3-1-2. First example of key existence check process Figure 6 is a flowchart of a first example of the key existence verification process in step S104. In the first example, the key existence verification process is performed by the control device 21. In the first example, the key 31 is a digital key, that is, the user terminal 30 also functions as the key 31. In the first example, the handover start request is not only sent from the user terminal 30 to the management system 10, but also from the user terminal 30, which functions as a digital key, to the control device (vehicle 1) via the aforementioned communication Ckey.

[0076] In step S300, the control device 21 determines whether vehicle 1 (control device 21) has received a handover start request via communication Ckey. If vehicle 1 has received the handover start request (step 300; Yes), the process proceeds to step S302.

[0077] In step S302, the control device 21 receives a handover start request from the user terminal 30 via communication Ckey and determines that the digital key (user terminal 30) is within a predetermined range R from the vehicle 1 at the time the handover start request was issued. That is, the control device 21 obtains (generates) a confirmation result Rcon indicating that the presence of the digital key (user terminal 30) has been confirmed. In addition, the predetermined range R corresponds to the range in which communication Ckey between the digital key (user terminal 30) and the vehicle 1 is possible, and the fact that the vehicle 1 was able to communicate with the user terminal 30 using communication Ckey means that the user terminal 30 (i.e., the digital key) is within the predetermined range R from the vehicle 1.

[0078] In step S304, following step S302, the control device 21 stores the generated verification result Rcon in the storage device 213.

[0079] According to the first example described above, the key existence verification process can be smoothly performed by using the communication Ckey between the user terminal 30, which functions as a digital key, and the vehicle 1.

[0080] 3-1-3. Second example of key existence check process Figure 7 is a flowchart showing a second example of the key existence verification process in step S104. In the second example, the key existence verification process is performed in cooperation with the control device 21 and the management system 10. In the second example, the key 31 may be either a physical key (e.g., a smart key) or a digital key.

[0081] The control device 21 periodically attempts to communicate with key 31 via Ckey, not only at the timing of the key existence confirmation process in step S104. Specifically, in step S400, the control device 21 attempts to communicate with key 31 via Ckey. Then, in step S402, the control device 21 obtains (generates) the communication result Rcom with key 31. The communication result Rcom is information indicating whether or not the communication Ckey is successful.

[0082] Furthermore, in the second example, in step S404, the control device 21 sends (uploads) the communication result Rcom to the management system 10 (server VB). The control device 21 repeatedly executes the processes in steps S400 to S404 at predetermined intervals. In this way, in the second example, the control device 21 periodically sends the communication result Rcom, which is the result of the periodically performed communication Ckey, to the management system 10.

[0083] As described above, when a handover start request is sent from the user terminal 30, the local management device 11 receives the handover start request via the servers UB and OB. The local management device 11 also periodically receives the communication result Rcom transmitted from the vehicle 1. In step S500, the local management device 11 determines whether or not it has received the communication result Rcom indicating that communication Ckey is established when it receives the handover start request.

[0084] If the result of step S500 is Yes, the local management device 11 receives a communication result Rcom indicating that communication Ckey was established when the handover start request was received, and determines that key 31 was within a predetermined range R from vehicle 1 when the handover start request was issued. In other words, the local management device 11 obtains (generates) a confirmation result Rcon indicating that the existence of key 31 has been confirmed. To add to this, the predetermined range R corresponds to the range in which communication Ckey between key 31 and vehicle 1 is possible, and the fact that vehicle 1 was able to communicate Ckey with key 31 means that key 31 is within the predetermined range R from vehicle 1.

[0085] In step S504, following step S502, the management system 10 stores the generated verification result Rcon in the storage device 123 or 113. More specifically, the local management device 11 sends an instruction to the server OB or VB to store the verification result Rcon, and the server OB or VB stores the verification result Rcon in its own storage device 123. Alternatively, the local management device 11 stores the verification result Rcon in the storage device 113.

[0086] According to the second example described above, the key existence verification process can be performed smoothly by utilizing the Ckey communication that is periodically performed between the key 31 and the vehicle 1.

[0087] Furthermore, the "predetermined range R" in the key existence confirmation process is not limited to the range in which communication Ckey between the key 31 and the vehicle 1 is possible, as in the first and second examples described above. That is, the predetermined range R may be, for example, a predetermined distance range from the vehicle 1. In this example, the control device 21 may determine whether or not the key 31 is within the predetermined distance range (=predetermined range R) by using, for example, the distance measurement result between the vehicle 1 and the key 31 using communication Ckey (e.g., UWB).

[0088] 3-1-4. Additional processing while parked using AVP service In the vehicle control system 100, when vehicle 1 has finished entering the parking area and is parked in a parking space 8 in the parking area 5, the following additional processing may be performed.

[0089] Figure 8 is a flowchart showing an example of the flow of additional processing during parking, which is included in the process related to disabling the immobilizer using key presence confirmation according to this embodiment. This additional processing is performed in cooperation with the management system 10 (mainly the local management device 11) and the control device 21.

[0090] In Figure 8, if the result of step S118 (see Figure 4 or Figure 5) is Yes, the process proceeds to step S600. In step S600, the local management device 11 determines whether user X unlocked vehicle 1 or boarded vehicle 1 while vehicle 1 was parked. User X's unlocking operation or boarding can be detected, for example, using sensors 22 installed in vehicle 1. For this reason, the local management device 11 can obtain detection information from the sensors 22 from vehicle 1 via servers VB, UB, and OB, for example, and make the determination in step S600 based on the obtained detection information. Alternatively, for this determination, the local management device 11 may detect user X's unlocking operation or boarding using, for example, an infrastructure sensor 13.

[0091] If user X has not performed an unlock operation or boarded the vehicle (step S600; No), the local management device 11 determines whether or not there is a request to exit the vehicle (step S120). In the process shown in Figure 8, if there is no request to exit the vehicle (step S120; No), the process returns to step S600. On the other hand, if user X has performed an unlock operation or boarded the vehicle (step S600; Yes), the process proceeds to step S602.

[0092] In step S602, the control device 21 disables the function to deactivate the vehicle 1's immobilizer in response to a request from the management system 10. That is, even though the predetermined period T has not yet elapsed, the control device 21 disables the deactivation of the immobilizer's restriction on starting the driving system 23.

[0093] In step S604, following step S602, the local management device 11 sends a notification to the user terminal 30 via servers OB and UB to confirm user X's intention to continue the AVP service. The process then proceeds to step S606.

[0094] In step S606, the local management device 11 communicates with server UB via server OB and determines whether it has received an AVP continuation request from user terminal 30 from user X requesting the continuation of AVP services. If an AVP continuation request is received (step S606; Yes), the process proceeds to step S608.

[0095] In step S608, the control device 21 activates the function to deactivate the immobilizer of vehicle 1 in response to a request from the management system 10. That is, in response to the AVP continuation request from user X, the control device 21 reactivates the deactivation of the immobilizer's restriction on starting the driving system 23.

[0096] On the other hand, if user X responds that they do not wish to continue the AVP service (step S606; No), the local management device 11 communicates with server UB via server OB to determine whether or not it has received a handback start request from user terminal 30 (step S610). If a handback start request is received (step S610; Yes), the local management device 11 starts the handback process (step S612). Then, when the handback process is completed (step S614; Yes), that is, when the handover period ends, the control device 21 or management system 10 deletes the confirmation result Rcon by the same process as in step S134 (step S616).

[0097] 3-2. Effects As described above, according to the vehicle control system 100 of this embodiment, when a handover start request is issued, the immobilizer's prohibition on starting the vehicle's driving system 23 is released in response to a start request from the management system 10, upon confirmation that the vehicle's key 31 is within a predetermined range R from the vehicle 1, even if user X is not near the vehicle 1. This allows the management system 10 to start the driving system 23 without requiring user X to wait near the vehicle 1 after the handover process is completed. This improves the convenience of user X in automated driving services (e.g., AVP service) within a predetermined area.

[0098] Furthermore, as in the first example described above (see Section 3-1-1), the predetermined period T during which the lifting of the immobilizer's prohibition on starting the driving system 23 is effective may end when the handover period ends. This allows the driving system 23 to be started in response to a start request from the management system 10 when the vehicle 1 enters and leaves the depot, while appropriately limiting the period during which the immobilizer's deactivation is effective, with consideration for the security of the vehicle 1.

[0099] Furthermore, as in the second example described above (see Section 3-1-1), the predetermined period T may end when vehicle 1 arrives at the pick-up area 4 for vehicle 1 to leave the depot. In this example, even during the handover period, the immobilizer deactivation becomes invalid after arrival at the pick-up area 4. This allows for the activation of the driving system 23 in response to activation requests from the management system 10 when vehicle 1 enters and leaves the depot, while more appropriately limiting the period during which the immobilizer deactivation is effective in order to further enhance the security of vehicle 1.

[0100] Furthermore, as described above in Section 3-1-4, if user X unlocks the doors of or enters the parked vehicle 1 while using the AVP service, the immobilizer deactivation may be disabled. This allows user X to quickly put vehicle 1 into a state where they can activate the driving system 23 themselves. Then, as described above, if user X requests the continuation of the AVP service after unlocking or entering the vehicle, the immobilizer deactivation may be re-enabled. This allows vehicle 1 to be returned to a state where the driving system 23 can be activated in response to an activation request from the management system 10 in preparation for subsequent departure using the AVP service. [Explanation of Symbols]

[0101] 1 Vehicle, 2 Parking lot, 3 Drop-off area, 4 Boarding area, 10 Management system, 11 Local management device, 12 Management server, 13 Infrastructure sensors, 20 Vehicle system, 21 Control device, 22 Sensors, 23 Driving system, 30 User terminal, 31 Key, 100 Vehicle control system, 111, 121, 211 Communication I / F, 112, 122, 212 Processor, 113, 123, 213 Storage device

Claims

1. A vehicle control system for controlling a vehicle that operates in a predetermined area according to remote instructions, A management system for managing the aforementioned vehicles, A control device mounted on the aforementioned vehicle and communicating with the aforementioned management system, Equipped with, The management system, in response to a handover start request from a user terminal operated by the user of the vehicle, initiates a handover process to transfer the operation rights of the vehicle from the user to the management system. Based on the result of the first communication between the control device and the vehicle key, the vehicle control system performs a key presence confirmation process to confirm that the key is within a predetermined range from the vehicle when the handover start request is issued. If the presence of the key is confirmed by the key presence confirmation process, the control device, provided that a predetermined period has elapsed since the key's presence was confirmed, will release the immobilizer's restriction on starting the vehicle's driving system in response to a request from the management system to start the vehicle's driving system. Vehicle control system.

2. A vehicle control system according to claim 1, The predetermined period ends when the handover period in which the operational authority is transferred from the user to the management system ends. Vehicle control system.

3. A vehicle control system according to claim 1, The predetermined period ends when the vehicle arrives at the boarding area in order to depart from the predetermined area. Vehicle control system.

4. A vehicle control system according to claim 2 or 3, The aforementioned designated area is a parking lot equipped with an automated valet parking service. If the user unlocks the doors or gets into the vehicle parked in the aforementioned parking lot using the automated valet parking service, the control device shall disable the release of the activation prohibition. Vehicle control system.

5. A vehicle control system according to claim 4, If, after the user has performed the unlock operation on the parked vehicle or has boarded it, the user operates the user terminal to request the continuation of the automatic valet parking service, the control device reactivates the release of the activation prohibition. Vehicle control system.

6. A vehicle control system according to claim 1, The user terminal stores key information for functioning as a digital key for the vehicle. The aforementioned key is the aforementioned digital key, The control device includes one or more storage devices, The handover start request is transmitted not only from the user terminal to the management system, but also from the user terminal, which functions as the digital key, to the control device via the first communication. The aforementioned key existence check process is: The control device determines, upon receiving the handover start request from the user terminal, that the digital key is within the predetermined range from the vehicle at the time the handover start request is issued. The control device stores the result of confirming the existence of the digital key in the one or more storage devices. including Vehicle control system.

7. A vehicle control system according to claim 6, The control device deletes the confirmation result from the one or more storage devices upon the end of the predetermined period. Vehicle control system.

8. A vehicle control system according to claim 1, The management system includes one or more storage devices. The aforementioned key existence check process is: The control device periodically attempts the first communication with the key and periodically transmits a communication result indicating whether or not the first communication is established to the management system. The management system determines that the key is within the predetermined range from the vehicle when the handover start request is issued, based on the communication result indicating that the first communication is established when the handover start request is received. The management system stores the result of confirming the existence of the key in one or more storage devices. including Vehicle control system.

9. A vehicle control system according to claim 8, The management system deletes the confirmation results from the one or more storage devices upon the end of the predetermined period. Vehicle control system.

10. A vehicle control method for controlling a vehicle that operates in a predetermined area according to remote instructions, wherein the vehicle control method is executed by a computer. The aforementioned vehicle control method is: In response to a handover start request from a user terminal operated by the user of the vehicle, the system initiates a handover process to transfer the operation rights of the vehicle from the user to the management system that manages the vehicle. Based on the result of the first communication between the control device mounted on the vehicle and the vehicle's key, a key existence confirmation process is performed to confirm that the key is within a predetermined range from the vehicle when the handover start request is issued. If the existence of the key is confirmed by the key existence confirmation process, and provided that it is within a predetermined period since the existence of the key was confirmed, the immobilizer of the vehicle will release the restriction on starting the vehicle's driving system in response to a request from the management system to start the vehicle's driving system. including Vehicle control method.

Images