vehicle

Abstract

Regarding automated valet parking in parking lots, this technology provides a system that allows vehicles to respond quickly to requests from the parking system. [Solution] The vehicle comprises a first controller configured to control the vehicle's operation and a second controller configured to receive information transmitted from the parking system before the first controller. A time synchronization request is a request sent from the parking system to the vehicle to determine the vehicle's clock. The second controller acquires and holds seed information necessary for error detection for verifying the time synchronization request before receiving the time synchronization request. When the second controller receives a time synchronization request from the parking system, it verifies the time synchronization request through error detection based on the seed information and sends a response to the time synchronization request back to the parking system.

Description

Technical Field

[0001] The present disclosure relates to Automated Valet Parking (AVP) for vehicles in parking lots.

Background Art

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

[0003] Non-Patent Document 1 discloses a standard related to automated valet parking.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Non-Patent Documents

[0005]

Non-Patent Document 1

Summary of the Invention

Problem to be Solved by the Invention

[0006] In automated valet parking, it is desirable to understand the relationship between the vehicle's clock and the parking system's (infrastructure system's) clock. Therefore, the parking system may send a request to the vehicle to obtain its clock information. In this case, it is desirable for the vehicle to respond quickly to the request from the parking system. [Means for solving the problem]

[0007] One aspect of this disclosure relates to vehicles compatible with automated valet parking in parking lots. The vehicle is A first controller configured to control the operation of the vehicle, A second controller is configured to receive information transmitted from a parking system that manages automated valet parking in a parking lot before the first controller. It is equipped with. A time synchronization request is a request sent from the parking system to the vehicle to determine the vehicle's clock. The second controller acquires and stores seed information necessary for error detection to verify the time synchronization request, prior to receiving the time synchronization request. When the second controller receives a time synchronization request from the parking system, it verifies the time synchronization request through error detection based on seed information and sends a response to the time synchronization request back to the parking system. [Effects of the Invention]

[0008] According to this disclosure, the second controller receives information transmitted from the parking system before the first controller. Upon receiving a time synchronization request from the parking system, the second controller verifies the time synchronization request based on seed information and sends a response to the time synchronization request back to the parking system. Therefore, the time from receiving the time synchronization request to responding is shortened compared to when the first controller performs the verification and response to the time synchronization request. In other words, the vehicle can quickly return a response to the time synchronization request from the parking system. [Brief explanation of the drawing]

[0009] [Figure 1] It is a conceptual diagram showing an overview of an automated valet parking system (AVP system). [Figure 2] It is a conceptual diagram for explaining an example of automated valet parking. [Figure 3] It is a conceptual diagram for explaining an overview of processing related to a time synchronization request. [Figure 4] It is a conceptual diagram for explaining checksum verification for a time synchronization request. [Figure 5] It is a conceptual diagram for explaining a comparative example. [Figure 6] It is a conceptual diagram for explaining in-vehicle processing. [Figure 7] It is a conceptual diagram for explaining an example of preparation of seed information. [Figure 8] It is a conceptual diagram for explaining in-vehicle communication verification processing. [Figure 9] It is a conceptual diagram showing an example of cooperation between vehicle identification processing and processing related to a time synchronization request. [Figure 10] It is a block diagram showing a configuration example of a vehicle. [Figure 11] It is a block diagram showing a configuration example of a parking lot system. DETAILED DESCRIPTION OF EMBODIMENTS

[0010] Embodiments of the present disclosure will be described with reference to the accompanying drawings. In the following description, automated valet parking may be referred to as "AVP".

[0011] 1. Automated Valet Parking System (AVP System) Figure 1 is a conceptual diagram showing an overview of an AVP system 10 according to the present embodiment. The AVP system 10 is a system for AVP in a parking lot. The AVP system 10 includes a vehicle 100, a user terminal 200, a back-end system 300, and a parking lot system 400.

[0012] Vehicle 100 is an object of Automated Valet Parking (AVP) in a parking lot and is compatible with AVP in the parking lot. Vehicle 100 has a function of autonomously traveling at least in parking lots.

[0013] User terminal 200 is a terminal operated by a user of the AVP service, that is, a user of vehicle 100. Examples of user terminal 200 include smartphones and personal computers.

[0014] Back-end system 300 manages AVP in one or more parking lots, users of AVP services, and the like. Parking lot system 400 is an infrastructure system installed in a specific parking lot and manages AVP in that parking lot. Back-end system 300 and parking lot system 400 may also be collectively referred to as a "management system". The management system manages AVP in parking lots.

[0015] Vehicle 100 and back-end system 300 can communicate with each other. For example, vehicle 100 and back-end system 300 communicate with each other using a mobile communication service. Further, in a parking lot, vehicle 100 and parking lot system 400 can perform wireless communication with each other. For example, vehicle 100 and parking lot system 400 perform wireless communication with each other using a wireless LAN. Further, user terminal 200 and back-end system 300 can communicate with each other. For example, user terminal 200 and back-end system 300 communicate with each other using a mobile communication service. Furthermore, back-end system 300 and parking lot system 400 can communicate with each other via wired or wireless connection.

[0016] 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 200 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 200 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 200. The backend system 300 also provides the reservation information to the parking system 400 of the reserved parking lot.

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

[0018] Vehicle 100 recognizes its surroundings using recognition sensors (e.g., cameras) mounted on it. Vehicle 100 drives safely while recognizing its surroundings. Multiple markers M (landmarks) may be placed within the parking lot. Markers M are used to guide vehicle 100 within the parking lot. For example, vehicle 100 acquires images of its surroundings using its camera and recognizes markers M based on the images. Then, based on the recognition results of markers M, vehicle 100 performs localization to estimate its position in the parking lot with high accuracy. Based on the estimated vehicle position, vehicle 100 drives automatically within the parking lot.

[0019] One or more infrastructure cameras (CAMs) may be installed in the parking lot. The infrastructure camera (CAM) photographs the parking lot and acquires images showing the conditions of the parking lot. The parking lot system 400 communicates with the infrastructure camera (CAM) and acquires the images taken by the infrastructure camera (CAM). The parking lot system 400 detects vehicles (100) that are shown in the images by analyzing the images. The parking lot system 400 also estimates the position of the vehicles (100) shown in the images. Furthermore, the parking lot system 400 manages each vehicle (100) in the parking lot based on its position. The parking lot system 400 may provide the vehicle (100) with its position information. The vehicle (100) may automatically drive within the parking lot based on the position information provided by the parking lot system 400.

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

[0021] An example of the checkout process is as follows: The user requests checkout using a user terminal 200 or the like. The management system communicates with vehicle 100 and starts vehicle 100. When checking out, the designated checkout area becomes the destination for vehicle 100. The parking system 400 sets the driving route TP (target trajectory) from the parking space in the parking lot to the checkout area. The parking system 400 sends a checkout instruction to vehicle 100. The checkout instruction includes information on the designated checkout area and driving route TP. In response to the checkout instruction, vehicle 100 automatically drives to the checkout area according to the driving route TP. In other words, vehicle 100 automatically drives to follow the driving route TP based on its position. Then, vehicle 100 automatically stops at the checkout area. Operational authority for vehicle 100 is transferred from the management system to the user. The user gets into vehicle 100. Vehicle 100 starts moving towards the next destination.

[0022] 2. Processing related to time synchronization requests 2-1. Requirements for Vehicles The vehicle clock CLK-VCL is the internal clock of vehicle 100. In other words, the vehicle clock CLK-VCL is the clock used in information processing within vehicle 100. On the other hand, the system clock CLK-RVO is the internal clock of parking system 400. In other words, the system clock CLK-RVO is the clock used in information processing within parking system 400. Note that in the following explanation, "RVO" may be used to mean parking system 400.

[0023] In AVP, it is desirable to understand the relationship between the vehicle clock CLK-VCL and the system clock CLK-RVO. In particular, the parking system 400 desires to understand the vehicle clock CLK-VCL in order to issue various instructions to the vehicle 100. For example, if the difference between the vehicle clock CLK-VCL and the system clock CLK-RVO is known, the vehicle clock CLK-VCL can be determined based on that difference and the system clock CLK-RVO. The parking system 400 according to this embodiment sends a request to the vehicle 100 to determine the vehicle clock CLK-VCL. This request will be referred to below as the "time synchronization request SYNC-REQ". Such a request is also specified in section 7.1.9 of Non-Patent Document 1.

[0024] Figure 3 is a conceptual diagram illustrating the overview of the process related to the time synchronization request (SYNC-REQ). Part (A) in Figure 3 shows the exchange of information between the parking system 400 and the vehicle 100.

[0025] First, the parking system 400 generates a time synchronization request (SYNC-REQ) and sends it to the vehicle 100. The parking system 400 also stores the value of the system clock CLK-RVO at the time of sending the time synchronization request (SYNC-REQ) as the transmission timestamp.

[0026] Vehicle 100 receives a time synchronization request (SYNC-REQ) transmitted from the parking system 400. Vehicle 100 processes the time synchronization request (SYNC-REQ) and generates a time synchronization response (SYNC-RSP). This time synchronization response (SYNC-RSP) includes the value of the vehicle clock (CLK-VCL) as a vehicle timestamp. For example, the time synchronization response (SYNC-RSP) includes the value of the vehicle clock (CLK-VCL) at the time of generation of the time synchronization response (SYNC-RSP) as a vehicle timestamp. Then, vehicle 100 sends the time synchronization response (SYNC-RSP) back to the parking system 400.

[0027] The parking system 400 receives a time synchronization response SYNC-RSP transmitted from the vehicle 100. The parking system 400 also stores the value of the system clock CLK-RVO at the time of receiving the time synchronization response SYNC-RSP as a reception timestamp.

[0028] The parking system 400 calculates the round trip time (RTT) between the parking system 400 and the vehicle 100 based on the transmitted timestamp and the received timestamp. The parking system 400 also obtains the vehicle timestamp included in the received time synchronization response SYNC-RSP. Furthermore, the parking system 400 calculates the difference between the vehicle clock CLK-VCL and the system clock CLK-RVO based on the vehicle timestamp and the RTT. The parking system 400 then determines the vehicle clock CLK-VCL based on that difference and the system clock CLK-RVO.

[0029] The parking system 400 may repeatedly generate and transmit a time synchronization request (SYNC-REQ) at regular intervals. A regular interval is, for example, 100ms.

[0030] Figure 3(B) shows an example of the processing time allocated to a series of processes. It is desirable that each process be completed in less than the allocated processing time. For example, a processing time of 10 ms is allocated to the generation and transmission of a time synchronization request (SYNC-REQ) in the parking system 400. A processing time of 10 ms is allocated to the transmission of the time synchronization request (SYNC-REQ) from the parking system 400 to the vehicle 100. A processing time of 60 ms is allocated to the processing of the time synchronization request (SYNC-REQ) in the vehicle 100, including the generation and transmission of a time synchronization response (SYNC-RSP). A processing time of 10 ms is allocated to the transmission of the time synchronization response (SYNC-RSP) from the vehicle 100 to the parking system 400. A processing time of 10 ms is allocated to the processing of the time synchronization response (SYNC-RSP) in the parking system 400.

[0031] Thus, it is desirable for vehicle 100 to quickly return a time synchronization response SYNC-RSP in response to a time synchronization request SYNC-REQ from the parking system 400. In the example above, it is desirable that the time from receiving the time synchronization request SYNC-REQ to sending the time synchronization response SYNC-RSP be less than 60ms. In other words, it is desirable for vehicle 100 to send the time synchronization response SYNC-RSP less than 60ms after receiving the time synchronization request SYNC-REQ.

[0032] Figure 4 is a conceptual diagram illustrating checksum verification of a time synchronization request (SYNC-REQ). To verify the reliability of communication between the parking system 400 and the vehicle 100, the vehicle 100 may be required to verify the time synchronization request (SYNC-REQ) received from the parking system 400. More specifically, the vehicle 100 verifies the time synchronization request (SYNC-REQ) using a known error detection method. For example, a known cyclic redundancy check (CRC) is used for error detection. This verification of the time synchronization request (SYNC-REQ) through error detection is conveniently referred to as "checksum verification." If an error is detected in the time synchronization request (SYNC-REQ) as a result of the checksum verification, the vehicle 100 notifies the parking system 400 of this. Such a requirement is also specified in section 7.5 of Non-Patent Document 1.

[0033] The time from receiving the time synchronization request (SYNC-REQ) to sending the time synchronization response (SYNC-RSP) in vehicle 100 includes the time required for checksum verification. It is desirable that vehicle 100 complete the series of in-vehicle processes, including checksum verification, in less than a predetermined time (e.g., 60 ms).

[0034] 2-2. In-vehicle processing First, a comparative example of in-vehicle processing will be described with reference to Figure 5. Vehicle 100 is equipped with a first controller CON1 and a second controller CON2. The first controller CON1 and the second controller CON2 can communicate with each other via an in-vehicle communication network.

[0035] The first controller CON1 is configured to control the operation of the vehicle 100. For example, the first controller CON1 automatically controls the driving of the vehicle 100 (at least one of driving, braking, and steering) by controlling the actuators of the vehicle 100. As another example, the first controller CON1 may automatically turn the lights of the vehicle 100 ON / OFF. As yet another example, the first controller CON1 may automatically open and close the doors of the vehicle 100. An example of the first controller CON1 is an autonomous driving controller for controlling the autonomous driving of the vehicle 100. An autonomous driving controller is also called an autonomous driving ECU (Electronic Control Unit). The first controller CON1 can also be called the first processing circuitry.

[0036] The second controller CON2 is configured to receive information transmitted from the parking system 400 before the first controller CON1. ​​In other words, the second controller CON2 is located on the communication path between the parking system 400 and the first controller CON1. ​​To put it another way, the second controller CON2 is positioned to relay communication between the parking system 400 and the first controller CON1. ​​The first controller CON1 receives information from and sends information to the parking system 400 via the second controller CON2. An example of the second controller CON2 is a communication controller for controlling wireless communication with the parking system 400. A communication controller is also called a communication ECU. The second controller CON2 can also be called the second processing circuitry.

[0037] In the comparative example shown in Figure 5, the first controller CON1 performs checksum verification and other operations. To this end, the first controller CON1 holds seed information necessary for checksum verification. For example, a known cyclic redundancy check (CRC) based on the seed is used for error detection in checksum verification (see Section 7.5 of Non-Patent Literature 1). The seed information is provided to the first controller CON1 in advance, before the reception of the time synchronization request SYNC-REQ.

[0038] The parking system 400 sends a time synchronization request (SYNC-REQ) to the vehicle 100. The vehicle 100's second controller CON2 receives the time synchronization request (SYNC-REQ). In the comparative example shown in Figure 5, the second controller CON2 forwards the received time synchronization request (SYNC-REQ) to the first controller CON1. ​​The first controller CON1 receives the time synchronization request (SYNC-REQ) from the second controller CON2. The first controller CON1 verifies the time synchronization request (SYNC-REQ) by performing a checksum verification based on the seed information it holds. Furthermore, the first controller CON1 generates a time synchronization response (SYNC-RSP) for the time synchronization request (SYNC-REQ). The first controller CON1 sends the time synchronization response (SYNC-RSP) to the second controller CON2. The second controller CON2 receives the time synchronization response (SYNC-RSP) from the first controller CON1. ​​Then, the second controller CON2 forwards the time synchronization response (SYNC-RSP) to the parking system 400.

[0039] In the comparative example shown in Figure 5, a series of in-vehicle processes, including checksum verification, take a relatively long time. For example, communication between the first controller CON1 and the second controller CON2 is required, which increases the in-vehicle processing time. Therefore, it may be difficult to complete the series of in-vehicle processes, including checksum verification, in less than a predetermined time (e.g., 60 ms). In other words, in the comparative example shown in Figure 5, it may be difficult to meet the requirements for the vehicle 100 described in Section 2-1 above.

[0040] Figure 6 is a conceptual diagram illustrating the in-vehicle processing according to this embodiment. According to this embodiment, the second controller CON2, not the first controller CON1, performs checksum verification and the like. For this purpose, the second controller CON2 holds the seed information necessary for checksum verification. As will be described later, the seed information is provided to the second controller CON2 in advance, before the reception of the time synchronization request SYNC-REQ.

[0041] The parking system 400 sends a time synchronization request (SYNC-REQ) to the vehicle 100. The vehicle 100's second controller CON2 receives the time synchronization request (SYNC-REQ). The second controller CON2 does not forward the time synchronization request (SYNC-REQ) to the first controller CON1. ​​The second controller CON2 verifies the time synchronization request (SYNC-REQ) by performing a checksum verification based on the seed information it holds. Furthermore, the second controller CON2 generates a time synchronization response (SYNC-RSP) for the time synchronization request (SYNC-REQ). Then, the second controller CON2 sends the time synchronization response (SYNC-RSP) to the parking system 400.

[0042] As described above, according to this embodiment, the time required for a series of in-vehicle processes, including checksum verification, is reduced compared to the comparative example. In other words, the time from receiving the time synchronization request SYNC-REQ to sending the time synchronization response SYNC-RSP is reduced. Therefore, it becomes easier to complete the series of in-vehicle processes, including checksum verification, in less than a predetermined time (e.g., 60ms). That is, it becomes possible to more reliably satisfy the requirements for the vehicle 100 described in Section 2-1 above.

[0043] 2-3. Preparing seed information Figure 7 is a conceptual diagram illustrating an example of seed information preparation. Prior to sending the time synchronization request SYNC-REQ, the parking system 400 sends instruction information INS to the vehicle 100. For example, the instruction information INS includes instructions regarding the operation of the vehicle 100, i.e., instructions to the first controller CON1. ​​This instruction information INS contains seed information necessary for checksum verification of the time synchronization request SYNC-REQ.

[0044] The second controller CON2 of the vehicle 100 receives instruction information INS transmitted from the parking system 400 before the time synchronization request SYNC-REQ. The second controller CON2 forwards the received instruction information INS to the first controller CON1. ​​The first controller CON1 receives the instruction information INS from the second controller CON2. The first controller CON1 processes according to the instructions indicated in the instruction information INS. Meanwhile, the first controller CON1 extracts the seed information contained in the instruction information INS and transmits that seed information to the second controller CON2. The second controller CON2 receives the seed information from the first controller CON1 and retains the received seed information. In this way, the second controller CON2 can obtain and retain the seed information necessary for checksum verification before receiving the time synchronization request SYNC-REQ.

[0045] As a variation, the second controller CON2 may directly retrieve seed information from the instruction information INS received from the parking system 400. Even in this case, the second controller CON2 can acquire and retain seed information before receiving the time synchronization request SYNC-REQ.

[0046] 2-4. In-vehicle communication verification process Figure 8 is a conceptual diagram illustrating the in-vehicle communication verification process. As described above, when the second controller CON2 receives a time synchronization request SYNC-REQ from the parking system 400, it performs a checksum verification of the time synchronization request SYNC-REQ. This checksum verification of the time synchronization request SYNC-REQ verifies the reliability of communication between the parking system 400 and the second controller CON2. However, this alone does not verify the reliability of in-vehicle communication between the first controller CON1 and the second controller CON2.

[0047] Therefore, when the second controller CON2 receives a time synchronization request SYNC-REQ from the parking system 400, the first controller CON1 and the second controller CON2 may verify the reliability of the in-vehicle communication between the first controller CON1 and the second controller CON2. This process is called the "in-vehicle communication verification process." For example, when the second controller CON2 receives a time synchronization request SYNC-REQ from the parking system 400, it executes the series of in-vehicle processes described above and requests the first controller CON1 to start the in-vehicle communication verification process. The method of the in-vehicle communication verification process is not particularly limited. For example, the first controller CON1 and the second controller CON2 are connected by Ethernet, and the in-vehicle communication verification process is performed using an error detection method commonly used in Ethernet.

[0048] 3. Integration with vehicle identification processing Let's consider identifying a specific vehicle 100 in a parking lot. The vehicle 100 to be identified will be referred to as "Target Vehicle 100T" below. The process of identifying Target Vehicle 100T in the parking lot will be referred to as "Vehicle Identification Process" below.

[0049] For example, the target vehicle 100T is a vehicle that intends to enter the parking lot using the AVP service. For example, if the first vehicle of the first user intends to enter the parking lot using the AVP service, that first vehicle is the target vehicle 100T. More specifically, the first vehicle parks in the parking area. The first user gets out of the first vehicle and requests to start AVP. When starting AVP for the first vehicle, it is desirable for the parking system 400 to accurately recognize which vehicle 100 in the parking area is the first vehicle. That is, it is desirable for the parking system 400 to identify the first vehicle (target vehicle 100T). By identifying the first vehicle, it becomes possible to accurately recognize the position of the first vehicle, i.e., the automatic driving start position. It also becomes possible to prevent a vehicle 100 that is not the first vehicle from mistakenly entering the parking lot.

[0050] In this embodiment, the "actions" performed by the target vehicle 100T are used for vehicle identification processing. An action is defined by a combination of a device that performs the action and the operating pattern of that device. Examples of visible actions include turning on or flashing lights, flashing turn signals, operating wipers, opening and closing doors, opening and closing windows, opening and closing door mirrors, opening and closing the hood, etc. Examples of audible actions include sounding the horn, starting the engine, etc. For example, the headlights or turn signals flash in a predetermined pattern over a predetermined period (e.g., a few seconds). As another example, the door mirrors may open and close in a predetermined pattern over a predetermined period. As yet another example, the horn may sound in a predetermined pattern over a predetermined period. The predetermined pattern of actions may be performed repeatedly over time.

[0051] The parking system 400 instructs the target vehicle 100T to perform a predetermined action. More specifically, the parking system 400 transmits an action instruction to the target vehicle 100T that instructs it to perform a predetermined action. For example, the action instruction includes the content of a predetermined action assigned to the target vehicle 100T. The target vehicle 100T receives the action instruction from the parking system 400. In response to the action instruction, the target vehicle 100T performs the predetermined action.

[0052] The parking lot is equipped with one or more infrastructure sensors for recognizing (detecting) actions. For example, an infrastructure sensor may include a camera for recognizing (detecting) visible actions. As another example, an infrastructure sensor may include a microphone for recognizing (detecting) audible actions. The parking lot system 400 can recognize (detect) actions performed by any vehicle 100 in the parking lot by using infrastructure sensors. Suppose it is recognized (detected) that a certain vehicle 100 performs a predetermined action within a predetermined judgment period after the transmission of an action instruction. In this case, the parking lot system 400 identifies the vehicle 100 as the target vehicle 100T. In other words, the parking lot system 400 identifies a vehicle 100 that performs a predetermined action within a predetermined judgment period as the target vehicle 100T.

[0053] Figure 9 is a conceptual diagram illustrating an example of the coordination between vehicle identification processing and processing related to time synchronization requests (SYNC-REQ).

[0054] First, as shown in [A] in Figure 9, the parking system 400 and the target vehicle 100T establish communication.

[0055] Next, as shown in [B] in Figure 9, the parking system 400 transmits instruction information INS to the target vehicle 100T. The instruction information INS includes an action instruction that tells the target vehicle 100T to perform a predetermined action. The predetermined action is, for example, to flash the lights. The action instruction can be said to be an instruction regarding the operation of the target vehicle 100T, that is, an instruction to the first controller CON1. ​​This instruction information INS also includes seed information necessary for checksum verification of the time synchronization request SYNC-REQ. At this stage, the second controller CON2 of the target vehicle 100T acquires and holds the seed information necessary for checksum verification (see Figure 7 above).

[0056] As shown in [C] in Figure 9, the target vehicle 100T performs a predetermined action in response to an action instruction. More specifically, the first controller CON1 of the target vehicle 100T receives instruction information INS via the second controller CON2 (see Figure 7 above). The first controller CON1 of the target vehicle 100T causes the target vehicle 100T to perform a predetermined action in response to the action instruction. The parking system 400 performs vehicle identification processing using infrastructure sensors. In other words, the parking system 400 identifies the vehicle 100 that has performed a predetermined action within a predetermined determination period as the target vehicle 100T.

[0057] After the vehicle identification process, as shown in [D] in Figure 9, the parking system 400 sends a time synchronization request (SYNC-REQ) to the target vehicle 100T. The second controller CON2 of the target vehicle 100T responds to the time synchronization request (SYNC-REQ) by performing a series of in-vehicle processes, including checksum verification (see Figure 6 above). Seed information obtained in advance during the vehicle identification process is used for checksum verification.

[0058] 4. Example of vehicle configuration Figure 10 is a block diagram showing an example configuration of a vehicle 100 according to this embodiment. The vehicle 100 includes a communication device 110, a sensor group 120, a running device 130, lights 140, and a controller 150.

[0059] The communication device 110 includes an antenna and a transmitting / receiving circuit.

[0060] The sensor group 120 includes recognition sensors, vehicle condition sensors, etc. Recognition sensors are used to recognize (detect) the surrounding conditions of the vehicle 100. Examples of recognition sensors include cameras, LiDAR (Laser Imaging Detection and Ranging), radar, etc. Vehicle condition sensors include speed sensors, acceleration sensors, yaw rate sensors, steering angle sensors, etc.

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

[0062] Light 140 includes turn signals (indicators), headlights, brake lights, fog lights, etc.

[0063] The controller 150 is a computer that controls the vehicle 100. The controller 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 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.

[0064] The vehicle control program 160 is a computer program for controlling the vehicle 100. The functions of the controller 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.

[0065] The controller 150 communicates with the backend system 300 and the parking system 400 via the communication device 110.

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

[0067] Additionally, the controller 150 controls the ON / OFF state of the light 140.

[0068] The controller 150 also acquires driving environment information 170 that indicates the driving environment of the vehicle 100. The driving environment information 170 is stored in the storage device 152. For example, the driving environment information 170 includes surrounding conditions information, vehicle status information, map information, location information, etc.

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

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

[0071] The map information is the map information of the parking lot in which vehicle 100 travels. The map information shows the layout of roads within the parking lot. The map information also shows the layout of stationary obstacles (e.g., walls, pillars) within the parking lot. Furthermore, the map information shows the layout of markers M within the parking lot. For example, the map information is provided by the parking lot system 400 that manages the parking lot. The controller 150 acquires the map information from the parking lot system 400.

[0072] The location information indicates the current position of vehicle 100 in the parking lot. For example, controller 150 obtains highly accurate location information through localization. Specifically, controller 150 calculates the approximate position of vehicle 100 in the parking lot based on vehicle status information (steering angle and speed). Controller 150 also recognizes markers M around vehicle 100 using recognition sensors. Controller 150 also obtains information on the placement of markers M around vehicle 100 from map information. Controller 150 corrects the position of vehicle 100 by matching the recognition results of markers M with their placement. This results in highly accurate location information.

[0073] Alternatively, the location information of the vehicle 100 may be estimated by the parking system 400 based on images captured by the infrastructure camera CAM. In this case, the controller 150 may obtain the location information from the parking system 400.

[0074] Furthermore, the controller 150 acquires information about the driving route TP in the parking lot. For example, the driving route TP is determined by the parking system 400, and the controller 150 acquires the driving route TP information from the parking system 400. In another example, the controller 150 may determine the driving route TP based on map information and location information. Then, based on the location information, the controller 150 performs vehicle driving control so that the vehicle 100 drives according to the driving route TP.

[0075] Controller 150 includes a first controller CON1 and a second controller CON2.

[0076] The first controller CON1 acquires driving environment information 170. The first controller CON1 also performs vehicle driving control. The first controller CON1 may also receive instruction information INS. The first controller CON1 may control the vehicle 100 to perform a predetermined action. For example, the first controller CON1 controls the ON / OFF state of the lights 140.

[0077] The second controller CON2 receives instruction information INS from the parking system 400 via the communication device 110. The instruction information INS includes seed information 180 necessary for checksum verification. The seed information 180 is pre-stored in the storage device 152 of the second controller CON2. The second controller CON2 also receives a time synchronization request SYNC-REQ from the parking system 400 via the communication device 110. In response to the time synchronization request SYNC-REQ, the second controller CON2 performs a series of in-vehicle processes, including checksum verification. The seed information 180 pre-stored in the storage device 152 is used for checksum verification of the time synchronization request SYNC-REQ. The second controller CON2 generates a time synchronization response SYNC-RSP. The second controller CON2 transmits the time synchronization response SYNC-RSP to the parking system 400 via the communication device 110.

[0078] 5. Example of a parking system configuration Figure 11 is a block diagram showing an example configuration of a parking system 400 according to this embodiment. The parking system 400 includes a communication device 410, one or more processors 420 (hereinafter simply referred to as processor 420), and one or more storage devices 430 (hereinafter simply referred to as storage devices 430).

[0079] The communication device 410 communicates with each vehicle 100. The communication device 410 also communicates with the backend system 300. Furthermore, the communication device 410 may communicate with the infrastructure camera CAM installed in the parking lot.

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

[0081] The management program 440 is a computer program for managing the parking lot. The functions of the parking system 400 may be realized through the cooperation of the processor 420 that executes the management program 440 and the storage device 430. The management program 440 is stored in the storage device 430. The management program 440 may be recorded on a computer-readable recording medium.

[0082] The processor 420 communicates with the vehicle 100 and the backend system 300 via the communication device 410. The processor 420 may also communicate with the user terminal 200 via the communication device 410 and the backend system 300.

[0083] Furthermore, the storage device 430 stores management information 450 for managing the parking lot. The management information 450 includes map information of the parking lot. The processor 420 may provide the map information to the vehicle 100 via the communication device 410. The management information 450 also indicates the usage status (availability) of parking spaces within the parking lot. Based on the management information 450, the processor 420 can assign an available parking space (destination) to the vehicle 100.

[0084] The management information 450 may include vehicle management information. The vehicle management information includes location information for each vehicle 100 in the parking lot. The processor 420 may communicate with each vehicle 100 via the communication device 410 and collect location information from each vehicle 100. Alternatively, the processor 420 may acquire images taken by infrastructure cameras CAM installed in the parking lot and estimate the location of each vehicle 100 based on those images. The vehicle management information may include a travel route TP assigned to each vehicle 100. The processor 420 can determine the travel route TP assigned to each vehicle 100 based on the location information, destination, and map information of the vehicle 100. The processor 420 may provide the travel route TP information to the vehicle 100 via the communication device 410.

[0085] The processor 420 transmits instruction information INS to the vehicle 100 via the communication device 410. The instruction information INS includes seed information 180 necessary for checksum verification in the vehicle 100. The processor 420 also transmits a time synchronization request SYNC-REQ to the vehicle 100 via the communication device 410. The processor 420 also receives a time synchronization response SYNC-RSP from the vehicle 100 via the communication device 410. [Explanation of Symbols]

[0086] 10. Automatic Valet Parking (AVP) System 100 vehicles 200 user terminals 300 backend systems 400 Parking System SYNC-REQ Time synchronization request SYNC-RSP Time Synchronization Response

Claims

1. A vehicle compatible with automated valet parking in a parking lot, A first controller configured to control the operation of the vehicle, A second controller is configured to receive information transmitted from the parking system that manages the automated valet parking in the aforementioned parking lot before the first controller. Equipped with, A time synchronization request is a request sent from the parking system to the vehicle in order to determine the vehicle's clock. The second controller acquires and stores seed information necessary for error detection for verifying the time synchronization request before receiving the time synchronization request. The second controller is configured to, upon receiving the time synchronization request from the parking system, verify the time synchronization request through error detection based on the seed information, and return a response to the time synchronization request to the parking system. vehicle.

2. A vehicle according to claim 1, The second controller is configured to verify the time synchronization request without forwarding the time synchronization request to the first controller, and to return the response to the time synchronization request to the parking system. vehicle.

3. A vehicle according to claim 1, The second controller is a communication controller that controls wireless communication with the parking system. vehicle.

4. A vehicle according to claim 1, When the second controller receives the time synchronization request from the parking system, the first controller and the second controller are configured to verify the reliability of the in-vehicle communication between the first controller and the second controller. vehicle.

5. A vehicle according to any one of claims 1 to 4, The second controller is further configured to receive instruction information transmitted from the parking system before the time synchronization request, The seed information is included in the instruction information. vehicle.

6. The vehicle according to claim 5, The instruction information includes instructions to the first controller. vehicle.

7. The vehicle according to claim 6, The second controller is further configured to transfer the instruction information to the first controller. The first controller is configured to receive the instruction information from the second controller and to transmit the seed information contained in the instruction information to the second controller. The second controller is further configured to hold the seed information received from the first controller. vehicle.

8. The vehicle according to claim 6, The instruction information includes an action instruction that instructs the vehicle to perform a predetermined action, The first controller is configured to cause the vehicle to perform the predetermined action in response to the action instruction. vehicle.

Images