Method for updating the specifications of an automated valet parking system and communication interface.

Abstract

Regarding automated valet parking in parking lots, ensure that the communication interface specifications between the vehicle and the parking system are the same. [Solution] The parking system manages automated valet parking in the parking lot. The IF specification version is the version of the communication interface specification for communication between the vehicle and the parking system. The vehicle-side IF version is the IF specification version supported by the vehicle. The parking-side IF version is one or more IF specification versions supported by the parking system. The target IF version is one of the parking-side IF versions. If the vehicle-side IF version is not included in the parking-side IF versions, the system suggests to the vehicle user that they update the vehicle-side IF version to the target IF version, or automatically updates the vehicle-side IF version to the target IF version.

Description

Technical Field

[0001] The present disclosure relates to Automated Valet Parking (AVP) in a parking lot.

Background Art

[0002] Patent Document 1 discloses automated valet parking in a parking lot. A vehicle corresponding to automated valet parking acquires route information from a parking lot system and autonomously travels along the acquired route.

[0003] Non-Patent Document 1 discloses standards for automated valet parking.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Non-Patent Documents

[0005]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0006] To implement automated valet parking in a parking lot, communication is necessary between the vehicle and the parking system (infrastructure system). Ideally, the communication interface specification versions on the vehicle and the parking system sides should match. If the communication interface specification versions do not match, automated valet parking may not be able to begin. [Means for solving the problem]

[0007] The first aspect relates to an automated valet parking system for the automated valet parking of vehicles in a parking lot. The parking system is a system that manages automated valet parking in a parking lot. Communication between the vehicle and the parking system is necessary for automated valet parking. The IF specification version is a version of the communication interface specification for communication between a vehicle and a parking system. The vehicle-side IF version is the IF specification version that the vehicle supports. The parking lot side IF version is one or more IF specification versions supported by the parking lot system. The target IF version is one of the parking lot-side IF versions. The automated valet parking system comprises one or more processors. One or more processors are configured to either suggest to the vehicle user that they update the vehicle-side IF version to the target IF version if the vehicle-side IF version is not included in the parking lot-side IF version, or to automatically update the vehicle-side IF version to the target IF version.

[0008] The second aspect concerns a method for updating communication interface specifications, which is performed by a computer and applied to automated valet parking of vehicles in a parking lot. The parking system is a system that manages automated valet parking in a parking lot. The IF specification version is a version of the communication interface specification for communication between a vehicle and a parking system. The vehicle-side IF version is the IF specification version that the vehicle supports. The parking lot side IF version is one or more IF specification versions supported by the parking lot system. The target IF version is one of the parking lot-side IF versions. The communication interface specification update method includes suggesting to the vehicle user that they update the vehicle-side IF version to the target IF version if the vehicle-side IF version is not included in the parking lot-side IF version, or automatically updating the vehicle-side IF version to the target IF version. [Effects of the Invention]

[0009] According to this disclosure, if the vehicle-side IF version is not included in the parking lot-side IF version, the vehicle-side IF version is automatically updated to a target IF version that is one of the parking lot-side IF versions. Alternatively, the vehicle user is suggested to update the vehicle-side IF version to a target IF version. As a result, the likelihood of the vehicle-side IF version matching the parking lot-side IF version increases. In other words, the matching of the vehicle-side IF version and the parking lot-side IF version is promoted. By matching the vehicle-side IF version with the parking lot-side IF version, it becomes possible to successfully start the AVP for vehicle 1 in the parking lot. [Brief explanation of the drawing]

[0010] [Figure 1] This is a conceptual diagram illustrating the overview of an automated valet parking system. [Figure 2] This is a conceptual diagram illustrating an example of automated valet parking. [Figure 3] This is a conceptual diagram illustrating the matching / mismatching of communication interface specification versions. [Figure 4] This is a conceptual diagram illustrating the process related to updating communication interface specifications. [Figure 5] It is a flowchart showing a first example of a process related to the update of the communication interface specification. [Figure 6] It is a flowchart showing a second example of a process related to the update of the communication interface specification. [Figure 7] It is a flowchart showing a third example of a process related to the update of the communication interface specification. [Figure 8] It is a flowchart showing still another example of a process related to the update of the communication interface specification. [Figure 9] It is a block diagram showing a configuration example of an in-vehicle system. [Figure 10] It is a block diagram showing a configuration example of a parking lot system. [Figure 11] It is a block diagram showing a configuration example of a back-end system.

Mode for Carrying Out the Invention

[0011] Embodiments of the present disclosure will be described with reference to the accompanying drawings.

[0012] 1. Automated Valet Parking (AVP) System FIG. 1 is a conceptual diagram showing an overview of an Automated Valet Parking (AVP) system 10 according to the present embodiment. The AVP system 10 is a system for AVP of a vehicle 1 in a parking lot. The AVP system 10 includes an in-vehicle system 100, a parking lot system 200, and a back-end system 300. The in-vehicle system 100 is mounted on the vehicle 1 that is the target of AVP and controls the vehicle 1. The parking lot system 200 is an infrastructure system installed in the parking lot and manages AVP in the parking lot. The back-end system 300 manages AVP in one or more parking lots, users of AVP services, and the like. The parking lot system 200 and the back-end system 300 can also be collectively referred to as a management system.

[0013] In a parking lot, the in-vehicle system 100 and the parking system 200 can communicate wirelessly with each other. For example, the in-vehicle system 100 and the parking system 200 can communicate wirelessly with each other using Wi-Fi. In addition, the in-vehicle system 100 and the backend system 300 can communicate with each other. For example, the in-vehicle system 100 and the backend system 300 can communicate with each other using a mobile communication service. Furthermore, the parking system 200 and the backend system 300 can communicate with each other via wired or wireless connection. Moreover, the backend system 300 and the user terminal UE of the user of vehicle 1 (i.e., the user of the AVP service) can communicate with each other.

[0014] An example of the AVP service reservation process is as follows: Assume that the user's membership information is pre-registered in the backend system 300. First, the user makes an AVP reservation. For example, the user operates the user terminal UE to input their user ID information, desired parking lot, desired date of use, desired time of use (scheduled entry time and scheduled exit time), etc. The user terminal UE sends reservation request information, including the entered information, to the backend system 300. The backend system 300 processes the reservation based on the reservation request information and sends a reservation completion notification to the user terminal UE. The backend system 300 also provides the reservation information to the parking system 200 of the reserved parking lot.

[0015] Figure 2 is a conceptual diagram illustrating an example of AVP in a parking lot.

[0016] The in-vehicle system 100 is mounted on vehicle 1 and controls vehicle 1. The in-vehicle system 100 recognizes the surrounding environment of vehicle 1 using recognition sensors (e.g., cameras) mounted on vehicle 1. The in-vehicle system 100 safely drives vehicle 1 while recognizing the surrounding environment of vehicle 1. Multiple markers M (landmarks) may be placed in the parking lot. The markers M are used to guide vehicle 1 within the parking lot. For example, the in-vehicle system 100 acquires images of the surroundings using a camera and recognizes the markers M based on the images. Then, based on the recognition results of the markers M, the in-vehicle system 100 performs localization processing to estimate the position of vehicle 1 in the parking lot with high accuracy. Based on the estimated vehicle position, the in-vehicle system 100 automatically drives vehicle 1 within the parking lot.

[0017] One or more infrastructure cameras (CAMs) may be installed in the parking lot. The infrastructure cameras (CAMs) photograph the parking lot and acquire images showing the conditions of the parking lot. The parking lot system 200 communicates with the infrastructure cameras (CAMs) and acquires the images taken by the infrastructure cameras (CAMs). The parking lot system 200 detects vehicles (1) that are shown in the images by analyzing the images. The parking lot system 200 also estimates the position of vehicles (1) that are shown in the images. Furthermore, the parking lot system 200 manages vehicles (1) in the parking lot based on their positions. The parking lot system 200 may provide the position information of vehicles (1) to the on-board system 100 of the vehicle (1). The on-board system 100 may automatically drive vehicle (1) within the parking lot based on the position information provided by the parking lot system 200.

[0018] An example of the parking process (check-in) is as follows: Vehicle 1 stops in the parking area. In the parking area, the user gets out of vehicle 1 and requests parking using a user terminal UE or the like. The management system (at least one of the parking system 200 and the backend system 300) authenticates the user and vehicle 1. Once authentication is complete, the control of vehicle 1 is transferred from the user to the management system. The management system also communicates with the in-vehicle system 100 and instructs the in-vehicle system 100 to start vehicle 1. The parking system 200 also assigns an available parking space to vehicle 1. The assigned available parking space becomes the target parking space, or destination, for vehicle 1 at the time of parking. Furthermore, the parking system 200 sets a driving route TP (target trajectory) from the parking area to the target parking space in the parking lot. The parking system 200 transmits a parking instruction to the in-vehicle system 100. The parking instruction includes information on the target parking space and the driving route TP. In response to the parking instruction, the in-vehicle system 100 directs vehicle 1 to the target parking space according to the driving path TP. In other words, the in-vehicle system 100 controls vehicle 1 to follow the driving path TP based on its position. Then, the in-vehicle system 100 parks vehicle 1 in the target parking space. After parking is complete, the management system instructs the in-vehicle system 100 to stop the operation of vehicle 1.

[0019] An example of the checkout process is as follows: The user requests checkout using a user terminal UE or the like. The management system communicates with the in-vehicle system 100 and instructs the in-vehicle system 100 to start vehicle 1. When checking out, the designated checkout area becomes the destination for vehicle 1. The parking system 200 sets the driving route TP (target trajectory) from the parking space in the parking lot to the checkout area. The parking system 200 transmits a checkout instruction to the in-vehicle system 100. The checkout instruction includes information on the designated checkout area and the driving route TP. In response to the checkout instruction, the in-vehicle system 100 drives vehicle 1 to the checkout area according to the driving route TP. In other words, the in-vehicle system 100 controls vehicle 1 to follow the driving route TP based on the vehicle's position. Then, the in-vehicle system 100 stops vehicle 1 in the checkout area. Operational authority for vehicle 1 is transferred from the management system to the user. The user gets into vehicle 1. Vehicle 1 departs for its next destination.

[0020] 2. Consistency of communication interface specifications To implement AVP in a parking lot, communication is required between vehicle 1 (in-vehicle system 100) and parking system 200. It is desirable that the versions of the "communication interface specification" match (are consistent) between vehicle 1 (in-vehicle system 100) and parking system 200. The communication interface specification is defined, for example, in Non-Patent Document 1. For instance, the communication interface specification includes the communication sequence between the in-vehicle system 100 and parking system 200. Another example is the communication interface specification including the message types used in communication between the in-vehicle system 100 and parking system 200. Yet another example is the communication interface specification including the message data protocol in communication between the in-vehicle system 100 and parking system 200 (see section 8.2 AVP Message Data Protocol in Non-Patent Document 1). These communication interface specifications may differ from version to version.

[0021] In the following explanation, the version of the communication interface specification for communication between vehicle 1 (in-vehicle system 100) and parking system 200 will be referred to as the "IF specification version." The IF specification version supported by vehicle 1 (in-vehicle system 100) will be referred to as the "vehicle-side IF version." The vehicle-side IF version can also be said to be the IF specification version available to vehicle 1 (in-vehicle system 100). Furthermore, one or more IF specification versions supported by parking system 200 will be referred to as the "parking-side IF version." The parking-side IF version can also be said to be the IF specification version available to parking system 200. There may be multiple parking-side IF versions. However, due to resource limitations of the ECU in in-vehicle system 100, it is highly likely that in-vehicle system 100 supports only one vehicle-side IF version. Nevertheless, there may be multiple vehicle-side IF versions.

[0022] Figure 3 is a conceptual diagram illustrating the agreement / disagreement between the vehicle-side IF version and the parking-side IF version. Agreement between the vehicle-side IF version and the parking-side IF version means that the vehicle-side IF version is included within one or more parking-side IF versions. In other words, agreement between the vehicle-side IF version and the parking-side IF version means that the vehicle-side IF version is the same as one or more parking-side IF versions. Conversely, disagreement between the vehicle-side IF version and the parking-side IF version means that the vehicle-side IF version is not included within one or more parking-side IF versions. In other words, disagreement between the vehicle-side IF version and the parking-side IF version means that the vehicle-side IF version is different from one or more parking-side IF versions. For example, in the example shown in Figure 3, the parking-side IF versions include versions 2.0 and 3.0. If the vehicle-side IF version is version 3.0, then the vehicle-side IF version is agreement with the parking-side IF version. On the other hand, if the vehicle-side IF version is version 1.0, then the vehicle-side IF version is disagreement with the parking-side IF version. Furthermore, if the vehicle's IF version is version 4.0, the vehicle's IF version does not match the parking lot's IF version.

[0023] Prior to starting AVP for vehicle 1 (the target vehicle) in the parking lot, the AVP system 10 verifies that the vehicle-side IF version and the parking lot-side IF version match. For example, the in-vehicle system 100 and the parking lot system 200 establish a TLS (Transport Layer Security) connection in accordance with a request from the backend system 300. After the TLS connection is established, within a predetermined time (e.g., 10 seconds), the in-vehicle system 100 and the parking lot system 200 verify that their respective IF specification versions match. If verification cannot be obtained within the predetermined time, or if the respective IF specification versions do not match, the AVP system 10 cancels AVP for vehicle 1 (the target vehicle) and notifies the user accordingly. In other words, if the vehicle-side IF version and the parking lot-side IF version do not match, AVP cannot be started.

[0024] Therefore, this embodiment proposes a technology that can facilitate the matching of the vehicle-side IF version and the parking lot-side IF version.

[0025] Figure 4 is a conceptual diagram illustrating the process related to updating the communication interface specifications according to this embodiment. In the example shown in Figure 4, the vehicle-side IF version is version 1.0, and the parking lot-side IF versions are versions 2.0 and 3.0. In other words, the vehicle-side IF version and the parking lot-side IF version do not match. First, the AVP system 10 recognizes that the vehicle-side IF version and the parking lot-side IF version do not match.

[0026] For example, before vehicle 1 arrives at the parking lot, a comparison is performed between the vehicle-side IF version and the parking lot-side IF version. The vehicle-side IF version information is obtained from the in-vehicle system 100. The parking lot-side IF version information is obtained from the parking lot system 200. The backend system 300 can communicate with the in-vehicle system 100 and the parking lot system 200 and can obtain the vehicle-side IF version information and the parking lot-side IF version information. Therefore, the backend system 300 may perform the comparison between the vehicle-side IF version and the parking lot-side IF version. As another example, the in-vehicle system 100 may obtain the parking lot-side IF version information from the parking lot system 200 via the backend system 300 and perform the comparison between the vehicle-side IF version and the parking lot-side IF version. As yet another example, the parking lot system 200 may obtain the vehicle-side IF version information from the in-vehicle system 100 via the backend system 300 and perform the comparison between the vehicle-side IF version and the parking lot-side IF version. In other words, the entity performing the comparison process may be any of the in-vehicle system 100, the parking lot system 200, or the backend system 300. In that sense, it can be said that the AVP system 10 compares the vehicle-side IF version with the parking lot-side IF version. Before vehicle 1 arrives at the parking lot, the AVP system 10 compares the vehicle-side IF version with the parking lot-side IF version and recognizes that the vehicle-side IF version and the parking lot-side IF version do not match.

[0027] Alternatively, after vehicle 1 arrives at the parking lot, the AVP system 10 may recognize that the vehicle-side IF version and the parking lot-side IF version do not match. For example, after vehicle 1 arrives at the parking lot, the in-vehicle system 100 and the parking lot system 200 establish a TLS connection in accordance with a request from the backend system 300. Within a predetermined time after the TLS connection is established, the in-vehicle system 100 and the parking lot system 200 verify whether their respective IF specification versions match. At this stage, it may be recognized that the vehicle-side IF version and the parking lot-side IF version do not match.

[0028] The backend system 300 maintains and manages a database of communication interface specifications (hereinafter referred to as IFDB). The in-vehicle system 100 can communicate with the backend system 300 as needed, download data for any communication interface specification managed in the IFDB, and implement that communication interface specification. In other words, the in-vehicle system 100 can update the vehicle-side IF version via software updates (SU) as needed.

[0029] If the vehicle-side IF version and the parking lot-side IF version do not match, it is desirable to update the vehicle-side IF version. The updated vehicle-side IF version must be one of the parking lot-side IF versions. This parking lot-side IF version will be referred to below as the "target IF version". If the communication interface specifications of the target IF version are managed in the IFDB, the in-vehicle system 100 can download the data of the communication interface specifications of the target IF version and update the vehicle-side IF version to the target IF version. It is possible that the target IF version may be older than the vehicle-side IF version before the update. In that case, the vehicle-side IF version will be downgraded to the target IF version, but in this embodiment, this is also included in the concept of "update".

[0030] For example, the AVP system 10 "automatically" updates the vehicle-side IF version to the target IF version. More specifically, the in-vehicle system 100 communicates with the backend system 300, downloads data on the communication interface specifications of the target IF version from the backend system 300, and automatically updates the vehicle-side IF version to the target IF version. If the backend system 300 detects a mismatch between the vehicle-side IF version and the parking lot-side IF version, the backend system 300 may instruct the in-vehicle system 100 to update the vehicle-side IF version to the target IF version. If the parking lot system 200 detects a mismatch between the vehicle-side IF version and the parking lot-side IF version, the parking lot system 200 may instruct the in-vehicle system 100 via the backend system 300 to update the vehicle-side IF version to the target IF version. In any case, the vehicle-side IF version can be updated to the target IF version.

[0031] As another example, the AVP system 10 may suggest to the user of vehicle 1 that they update the vehicle-side IF version to the target IF version. More specifically, the backend system 300 communicates with the user's user terminal UE and sends an "update proposal notification" to the user terminal UE suggesting that they update the vehicle-side IF version to the target IF version. If the in-vehicle system 100 recognizes a mismatch between the vehicle-side IF version and the parking lot-side IF version, the in-vehicle system 100 may request the backend system 300 to send an update proposal notification. If the parking lot system 200 recognizes a mismatch between the vehicle-side IF version and the parking lot-side IF version, the parking lot system 200 may request the backend system 300 to send an update proposal notification. In any case, an update proposal notification can be sent to the user terminal UE. Upon receiving the update proposal notification, the user accepts or rejects the update of the vehicle-side IF version. If the user accepts the update of the vehicle-side IF version, the backend system 300 receives an acceptance response from the user terminal UE. The backend system 300 then instructs the in-vehicle system 100 to update the vehicle-side IF version to the target IF version.

[0032] As described above, according to this embodiment, if the vehicle-side IF version is not included in the parking lot-side IF version, the vehicle-side IF version is automatically updated to a target IF version that is one of the parking lot-side IF versions. Alternatively, the vehicle user is suggested to update the vehicle-side IF version to a target IF version. As a result, the likelihood of the vehicle-side IF version matching the parking lot-side IF version increases. In other words, the matching of the vehicle-side IF version and the parking lot-side IF version is promoted. By matching the vehicle-side IF version with the parking lot-side IF version, it becomes possible to successfully start the AVP of vehicle 1 in the parking lot.

[0033] 3. Example of a processing flow The following describes an example of the processing flow according to this embodiment. As mentioned above, the processing entity may be any of the in-vehicle system 100, the parking system 200, and the backend system 300, or a combination of two or more of them. This is because the backend system 300 can communicate with the in-vehicle system 100 and the parking system 200, and can share various information between the in-vehicle system 100, the parking system 200, and the backend system 300. In the following description, the processing entity will be referred to as "AVP system 10," which means that the processing entity may be any of the in-vehicle system 100, the parking system 200, and the backend system 300, or a combination of two or more of them. More generally, the processing entity can also be called "one or more processors" or "processing circuitry."

[0034] 3-1. Example 1 Figure 5 is a flowchart showing a first example of the processing flow related to updating the communication interface specification according to this embodiment.

[0035] In step S20, the AVP system 10 obtains the latest information on the vehicle-side IF version from the vehicle-side system 100 of vehicle 1 (the target vehicle). The AVP system 10 also obtains the latest information on the parking lot-side IF version from the parking lot system 200.

[0036] In step S30, the AVP system 10 compares the acquired vehicle-side IF version with the acquired parking-side IF version to determine whether the vehicle-side IF version is included in the parking-side IF version. In other words, the AVP system 10 determines whether the current vehicle-side IF version matches the parking-side IF version. If the vehicle-side IF version is included in the parking-side IF version, i.e., if the vehicle-side IF version matches the parking-side IF version (step S30; Yes), the process proceeds to step S40. On the other hand, if the vehicle-side IF version is not included in the parking-side IF version, i.e., if the vehicle-side IF version does not match the parking-side IF version (step S30; No), the process proceeds to step S50.

[0037] In step S40, the AVP system 10 authorizes AVP for vehicle 1 (the target vehicle).

[0038] In step S50, the AVP system 10 determines whether it is possible to obtain the target IF version, which is one of the parking lot-side IF versions. If the communication interface specifications of the target IF version are included in the IFDB of the backend system 300, the target IF version is obtainable. If the target IF version is obtainable (step S50; Yes), the process proceeds to step S60. On the other hand, if the target IF version is not obtainable (step S50; No), the process proceeds to step S90.

[0039] In step S60, the AVP system 10 obtains the communication interface specifications for the target IF version from the IFDB of the backend system 300. The AVP system 10 then automatically updates the vehicle-side IF version to the target IF version. After that, the process proceeds to step S40.

[0040] In step S90, the AVP system 10 disables AVP for vehicle 1 (the target vehicle).

[0041] 3-2. Second Example Figure 6 is a flowchart showing a second example of the processing flow related to updating the communication interface specification according to this embodiment. Explanations that overlap with the second example described above will be omitted as appropriate.

[0042] In step S50, the AVP system 10 determines whether it is possible to obtain the target IF version, which is one of the parking lot-side IF versions. If the target IF version is obtainable (step S50; Yes), the process proceeds to step S70.

[0043] In step S70, the AVP system 10 proposes to the user of vehicle 1 (the target vehicle) that they update the vehicle-side IF version to the target IF version. More specifically, the AVP system 10 sends an update proposal notification to the user's user terminal UE proposing that they update the vehicle-side IF version to the target IF version. The user terminal UE sends a user response to the AVP system 10 indicating the user's acceptance or rejection.

[0044] In step S80, the AVP system 10 determines whether the user has agreed to the update of the vehicle-side IF version. If the user rejects the update of the vehicle-side IF version (step S80; No), the process proceeds to step S90.

[0045] On the other hand, if the user agrees to update the vehicle-side IF version (step S80; Yes), the process proceeds to step S40. In step S40, the AVP system 10 authorizes AVP for vehicle 1 (the target vehicle). The AVP system 10 only needs to update the vehicle-side IF version to the target IF version before AVP starts.

[0046] 3-3. Third Example Figure 7 is a flowchart illustrating a third example of the process related to updating the communication interface specifications. Explanations that overlap with the first and second examples described above are omitted as appropriate.

[0047] In step S10, the AVP system 10 determines whether a predetermined trigger has occurred. If a predetermined trigger has occurred (step S10; Yes), the AVP system 10 performs the processing described in the first or second example above. That is, in response to a predetermined trigger, the AVP system 10 performs the processing described in the first or second example above.

[0048] A first example of a predetermined trigger is when a user requests a reservation for an AVP (Accessible Parking Facility) in a parking lot. When requesting an AVP reservation, the user operates the user terminal UE to input information such as the user's ID, desired parking lot, desired date of use, desired time of use (scheduled entry time and scheduled exit time). The user terminal UE sends the reservation request information, including the entered information, to the backend system 300. When the backend system 300 receives the reservation request information, the AVP system 10 determines that a predetermined trigger has occurred.

[0049] A second example of a predetermined trigger is an update of the parking-side IF version in the parking system 200. The administrator of the parking system 200 may update the parking-side IF version at any time. When the parking system 200 detects an update to the parking-side IF version, the AVP system 10 determines that a predetermined trigger has occurred. In this case, the AVP system 10 may perform the processing described in the first or second example above for all vehicles 1 of users who may use the AVP.

[0050] After the AVP reservation for vehicle 1 in a certain parking lot is completed, the parking lot side IF version may be updated in the parking lot system 200 of that parking lot before vehicle 1 arrives at the parking lot. In this case, the AVP system 10 may perform the processing described in the first or second example above with respect to vehicle 1 of the user who made the AVP reservation.

[0051] A third example of a predetermined trigger is the arrival of a predetermined time (e.g., several hours before) the scheduled time of vehicle entry specified by the user at the time of reservation. When the predetermined time before the scheduled time of vehicle entry arrives, the AVP system 10 determines that the predetermined trigger has occurred.

[0052] A fourth example of a predetermined trigger is when, after vehicle 1 arrives at the parking lot, a mismatch is discovered between the vehicle-side IF version and the parking lot-side IF version in the entry area. In the entry area, the in-vehicle system 100 and the parking lot system 200 establish a TLS connection in accordance with a request from the backend system 300. After the TLS connection is established, within a predetermined time (e.g., 10 seconds), the in-vehicle system 100 and the parking lot system 200 verify whether their respective IF specification versions match. If it is found at this stage that the vehicle-side IF version and the parking lot-side IF version do not match, the AVP system 10 determines that a predetermined trigger has occurred.

[0053] 3-4. The fourth example Let us elaborate further on the first example of a given trigger described above, namely, the case where the given trigger is "a user requests an AVP reservation in the parking lot."

[0054] If the vehicle-side IF version matches the parking lot-side IF version in step S30 (step S30; Yes), the process proceeds to step S40. In step S40, the AVP system 10 accepts the reservation requested by the user. The AVP system 10 also notifies the user via the user terminal UE that the reservation has been successfully accepted.

[0055] If the target IF version cannot be obtained in step S50 (step S50; No), the process proceeds to step S90. In step S90, the AVP system 10 does not accept the reservation requested by the user. The AVP system 10 also notifies the user via the user terminal UE that the reservation cannot be accepted.

[0056] In step S60, if the vehicle-side IF version is automatically updated to the target IF version, the process proceeds to step S40. In step S40, the AVP system 10 accepts the reservation requested by the user. The AVP system 10 also notifies the user via the user terminal UE that the reservation has been successfully accepted.

[0057] If the user agrees to update the vehicle-side IF version in step S80 (step S80; Yes), the process proceeds to step S40. In step S40, the AVP system 10 accepts the reservation requested by the user. The AVP system 10 also notifies the user via the user terminal UE that the reservation has been successfully accepted. Subsequently, before the AVP starts, the AVP system 10 updates the vehicle-side IF version to the target IF version.

[0058] If the user rejects the update of the vehicle-side IF version in step S80 (step S80; No), the process proceeds to step S90. In step S90, the AVP system 10 does not accept the reservation requested by the user. The AVP system 10 also notifies the user through the user terminal UE that the reservation cannot be accepted.

[0059] Figure 8 is a flowchart illustrating yet another example of the process related to updating the communication interface specification. In step S100, the AVP system 10 estimates the update completion timing at which the update of the vehicle-side IF version to the target IF version is completed. For example, the time required to update the vehicle-side IF version to the target IF version is several minutes. In step S110, the AVP system 10 determines whether the update completion timing is later than the desired service entry time specified in the reservation. If the update completion timing is later than the desired service entry time specified in the reservation (step S110; Yes), the process proceeds to step S120. In step S120, the AVP system 10 proposes to the user via the user terminal UE that they delay the desired service entry time.

[0060] 4. Example Configuration 4-1. Example of an in-vehicle system configuration Figure 9 is a block diagram showing an example configuration of the in-vehicle system 100 according to this embodiment. The in-vehicle system 100 includes a communication device 110, a sensor group 120, a driving device 130, and a control device 150.

[0061] The communication device 110 communicates with the outside world via a communication network. For example, the communication device 110 communicates with the parking system 200 of the parking lot via a wireless LAN. The communication device 110 also communicates with the backend system 300.

[0062] The sensor group 120 includes a recognition sensor 121, a vehicle condition sensor 122, etc. The recognition sensor 121 is used to recognize (detect) the surrounding conditions of the vehicle 1. Examples of recognition sensors 121 include a camera, LiDAR (Laser Imaging Detection and Ranging), radar, etc. The vehicle condition sensor 122 includes a speed sensor, acceleration sensor, yaw rate sensor, steering angle sensor, etc.

[0063] The running gear 130 includes a steering gear, a drive gear, and a braking gear. The steering gear steers the wheels. For example, the steering gear includes an electric power steering (EPS) system. The drive gear is a power source that generates driving force. Examples of drive gears include an engine, an electric motor, an in-wheel motor, etc. The braking gear generates braking force.

[0064] The control device 150 is a computer that controls the vehicle 1. The control device 150 includes one or more processors 151 (hereinafter simply referred to as processor 151) and one or more storage devices 152 (hereinafter simply referred to as storage devices 152). The processor 151 performs various processes. Examples of processors 151 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, and / or combinations thereof. The processor 151 can also be called a processing circuitry. The storage devices 152 store various information. Examples of storage devices 152 include volatile memory, non-volatile memory, HDDs (Hard Disk Drives), SSDs (Solid State Drives), etc.

[0065] The vehicle control program 160 is a computer program for controlling vehicle 1. The functions of the control device 150 may be realized through the cooperation of a processor 151 that executes the vehicle control program 160 and a storage device 152. The vehicle control program 160 is stored in the storage device 152. Alternatively, the vehicle control program 160 may be recorded on a computer-readable recording medium.

[0066] The control device 150 performs vehicle driving control to control the movement of vehicle 1. Vehicle driving control includes steering control, acceleration control, and deceleration control. The control device 150 performs vehicle driving control by controlling the driving device 130 (steering device, drive device, braking device).

[0067] Furthermore, the control device 150 communicates with the parking system 200 and the backend system 300 via the communication device 110. The storage device 152 may store information on the version of the communication interface specification in the in-vehicle system 100, i.e., the vehicle-side IF version. The control device 150 may also perform processing related to the communication interface specification update described in Sections 2 and 3 above.

[0068] The control device 150 also acquires various types of information. This information is stored in the storage device 152.

[0069] The surrounding environment information 171 shows the recognition results from the recognition sensor 121. The surrounding environment information 171 may also include object information about objects recognized by the recognition sensor 121. Examples of objects around vehicle 1 include obstacles, white lines, marker M, etc. Examples of obstacles include walls, pillars, other vehicles, etc. The object information shows the relative position and relative velocity of the object with respect to vehicle 1.

[0070] Vehicle status information 172 indicates the vehicle status detected by the vehicle status sensor 122. Examples of vehicle status include speed, acceleration, yaw rate, steering angle, etc.

[0071] Map information 173 is map information of the parking lot in which vehicle 1 travels. Map information 173 shows the layout of roads within the parking lot. Map information 173 also shows the layout of stationary obstacles (e.g., walls, pillars) within the parking lot. Furthermore, map information 173 shows the layout of markers M within the parking lot. For example, map information 173 is provided by the parking lot system 200 that manages the parking lot. The control device 150 acquires map information 173 from the parking lot system 200 via the communication device 110.

[0072] Location information 174 indicates the current position of vehicle 1 in the parking lot. For example, the control device 150 obtains highly accurate location information 174 through localization. Specifically, the control device 150 calculates the approximate position of vehicle 1 in the parking lot based on vehicle state information 172 (steering angle and speed). The control device 150 also recognizes markers M around vehicle 1 using the recognition sensor 121. The control device 150 also obtains information on the placement of markers M around vehicle 1 from map information 173. The control device 150 corrects the position of vehicle 1 by matching the recognition results of markers M with their placement. This results in highly accurate location information 174.

[0073] Alternatively, the location information 174 of vehicle 1 may be estimated by the parking system 200 based on images captured by the infrastructure camera CAM. In this case, the control device 150 may obtain the location information 174 from the parking system 200 via the communication device 110.

[0074] Furthermore, the control device 150 acquires information on the driving route TP in the parking lot. For example, the driving route TP is determined by the parking system 200, and the control device 150 acquires the driving route TP information from the parking system 200 via the communication device 110. In another example, the control device 150 may determine the driving route TP based on map information 173 and location information 174. Then, based on the location information 174, the control device 150 performs vehicle driving control so that vehicle 1 travels according to the driving route TP.

[0075] 5-2. Example of a parking system configuration Figure 10 is a block diagram showing an example configuration of the parking system 200 according to this embodiment. The parking system 200 includes a communication device 210, one or more processors 220 (hereinafter simply referred to as processor 220), and one or more storage devices 230 (hereinafter simply referred to as storage devices 230).

[0076] The communication device 210 communicates with the in-vehicle system 100 of each vehicle 1. For example, the communication device 210 communicates with the in-vehicle system 100 via a wireless LAN. The communication device 210 also communicates with the backend system 300. Furthermore, the communication device 210 may also communicate with the infrastructure camera CAM installed in the parking lot.

[0077] The processor 220 performs various processes. Examples of the processor 220 include general-purpose processors, application-specific processors, CPUs, GPUs, ASICs, FPGAs, integrated circuits, and / or combinations thereof. The processor 220 can also be called processing circuitry. The storage device 230 stores various information. Examples of storage devices 230 include volatile memory, non-volatile memory, HDDs, SSDs, etc.

[0078] The management program 240 is a computer program for managing the parking lot. The functions of the parking system 200 may be realized through the cooperation of the processor 220 that executes the management program 240 and the storage device 230. The management program 240 is stored in the storage device 230. The management program 240 may be recorded on a computer-readable recording medium.

[0079] The processor 220 communicates with the in-vehicle system 100 and the backend system 300 via the communication device 210. The storage device 230 may store information on the version of the communication interface specification in the parking system 200, i.e., the parking-side IF version. The processor 220 may perform processing related to the communication interface specification update described in Sections 2 and 3 above.

[0080] Furthermore, the storage device 230 stores management information 250 for managing the parking lot. The management information 250 includes map information of the parking lot. The map information is the same as the map information 173 described above. The processor 220 may provide the map information to the in-vehicle system 100 via the communication device 210. The management information 250 also indicates the usage status (availability) of parking spaces within the parking lot. Based on the management information 250, the processor 220 can assign an available parking space (destination) to the vehicle 1.

[0081] The management information 250 may include vehicle management information. The vehicle management information includes location information 174 for each vehicle 1 in the parking lot. The processor 220 may communicate with each vehicle 1 via the communication device 210 and collect location information 174 from each vehicle 1. Alternatively, the processor 220 may acquire images taken by infrastructure cameras CAM installed in the parking lot and estimate the location of each vehicle 1 based on those images. The vehicle management information may include a driving route TP assigned to each vehicle 1. The processor 220 can determine the driving route TP assigned to each vehicle 1 based on the location information 174 of the vehicle 1, the destination, and map information. The processor 220 may provide the driving route TP information to the in-vehicle system 100 of the vehicle 1 via the communication device 210.

[0082] 5-3. Example of a backend system configuration Figure 11 is a block diagram showing an example configuration of the backend system 300 according to this embodiment. The backend system 300 includes a communication device 310, one or more processors 320 (hereinafter simply referred to as processor 320), and one or more storage devices 330 (hereinafter simply referred to as storage devices 330).

[0083] The communication device 310 communicates with the in-vehicle system 100 of each vehicle 1. The communication device 310 also communicates with the parking system 200 of each parking lot. Furthermore, the communication device 310 communicates with the user terminal UE of each user.

[0084] The processor 320 performs various processes. Examples of the processor 320 include general-purpose processors, application-specific processors, CPUs, GPUs, ASICs, FPGAs, integrated circuits, and / or combinations thereof. The processor 320 can also be called processing circuitry. The storage device 330 stores various information. Examples of storage devices 330 include volatile memory, non-volatile memory, HDDs, SSDs, etc.

[0085] The management program 340 is a computer program for managing the AVP in the parking lot. The functions of the backend system 300 may be realized through the cooperation of the processor 320, which executes the management program 340, and the storage device 330. The management program 340 is stored in the storage device 330. The management program 340 may be recorded on a computer-readable recording medium.

[0086] The storage device 330 stores management information 350. The management information 350 may include user information and reservation information for each user. The management information 350 may also include facility information and reservation status information for each parking lot. When the processor 320 receives reservation request information from a user, it may perform reservation processing based on the management information 350.

[0087] Furthermore, the storage device 330 stores the communication interface specification database IFDB. The processor 320 communicates with the in-vehicle system 100 and the parking system 200 via the communication device 310. The processor 320 may also perform processing related to the communication interface specification update described in Sections 2 and 3 above. [Explanation of symbols]

[0088] 1 vehicle 10. Automatic Valet Parking (AVP) System 100 In-vehicle systems 200 Parking System 300 backend systems IFDB Communication Interface Specification Database UE user terminal

Claims

1. An automated valet parking system for automated vehicle valet parking in a parking lot, The parking system is a system for managing the automated valet parking in the parking lot. Communication between the vehicle and the parking system is necessary for the automated valet parking. The IF specification version is a version of the communication interface specification for the aforementioned communication, The vehicle-side IF version is the IF specification version that the vehicle supports. The parking lot side IF version is one or more IF specification versions supported by the aforementioned parking lot system. The target IF version is one of the parking lot side IF versions mentioned above. The automated valet parking system comprises one or more processors, The one or more processors are configured to suggest to the vehicle user that they update the vehicle-side IF version to the target IF version if the vehicle-side IF version is not included in the parking lot-side IF version, or to automatically update the vehicle-side IF version to the target IF version. Automatic valet parking system.

2. An automated valet parking system according to claim 1, The one or more processors further include: The latest information on the vehicle-side IF version and the latest information on the parking lot-side IF version are obtained. By comparing the acquired vehicle-side IF version with the acquired parking lot-side IF version, it is determined whether or not the vehicle-side IF version is included in the parking lot-side IF version. It is configured in such a way Automatic valet parking system.

3. An automated valet parking system according to claim 1, The one or more processors further include: In response to a predetermined trigger, the latest information on the vehicle-side IF version and the latest information on the parking lot-side IF version are obtained. By comparing the acquired vehicle-side IF version with the acquired parking lot-side IF version, it is determined whether or not the vehicle-side IF version is included in the parking lot-side IF version. It is configured in such a way Automatic valet parking system.

4. An automated valet parking system according to claim 3, The predetermined trigger includes the user requesting a reservation for the automated valet parking at the parking lot. Automatic valet parking system.

5. An automated valet parking system according to claim 4, The one or more processors further include: If the aforementioned target IF version cannot be obtained, the reservation will not be accepted, and the user will be notified that the reservation cannot be accepted. It is configured in such a way Automatic valet parking system.

6. An automated valet parking system according to claim 4, The one or more processors further include: If the user agrees to update the vehicle-side IF version to the target IF version, or if the vehicle-side IF version is automatically updated to the target IF version, the reservation will be accepted. It is configured in such a way Automatic valet parking system.

7. An automated valet parking system according to claim 4, The one or more processors further include: The update completion timing is estimated for when the vehicle-side IF version is updated to the target IF version. If the completion time of the update is later than the desired entry time specified in the reservation, the user will be offered the option to postpone the desired entry time. It is configured in such a way Automatic valet parking system.

8. An automated valet parking system according to any one of claims 4 to 7, The predetermined trigger further includes the fact that the parking system's IF version has been updated after the reservation has been completed. Automatic valet parking system.

9. An automated valet parking system according to claim 3, The predetermined trigger includes the update of the parking system's IF version. Automatic valet parking system.

10. A method for updating the communication interface specification, which is performed by a computer and is applied to automated valet parking of vehicles in a parking lot, The parking system is a system for managing the automated valet parking in the parking lot. Communication between the vehicle and the parking system is necessary for the automated valet parking. The IF specification version is a version of the communication interface specification for the aforementioned communication, The vehicle-side IF version is the IF specification version that the vehicle supports. The parking lot side IF version is one or more IF specification versions supported by the aforementioned parking lot system. The target IF version is one of the parking lot side IF versions mentioned above. The communication interface specification update method is: If the vehicle-side IF version is not included in the parking lot-side IF version, the system may suggest to the vehicle user that they update the vehicle-side IF version to the target IF version, or it may automatically update the vehicle-side IF version to the target IF version. Automatic valet parking system.

Images