JP7754333B2 - In-vehicle device - Google Patents

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based on Patent Application No. 2022-137297 filed in Japan on August 30, 2022, and the contents of the original application are incorporated by reference in their entirety.

The disclosure in this specification relates to technology that assists on-street parking.

Patent document 1 discloses a server- or cloud-based parking facilitation system that collects sensor information from multiple sensors, identifies available parking spaces, and generates a parking space map.

Japanese Patent Application Laid-Open No. 2020-109628

However, in a system like that described in Patent Document 1, in which all sensor information is aggregated in a center such as a server or cloud, the amount of sensor information becomes enormous. This raises concerns about the impact on the communication load required to aggregate the sensor information and the processing load required to identify parking spaces from the sensor information.

One of the purposes of the disclosure of this specification is to provide an in-vehicle device that works in conjunction with a parking assistance service.

Another aspect disclosed herein is an on-board device that is mounted on a vehicle and includes at least one processor for executing a process to support on-street parking of the vehicle, and is capable of communicating with a roadside unit that is installed on a roadside and includes a roadside sensor that senses a sensing area of a road surrounding an installation location,
At least one processor
Obtaining dynamic available parking area data from a roadside device or a server that collects information from the roadside devices;
Proposing a parking position to an occupant of the vehicle based on the available parking area data;
Based on the acceptance of the proposed parking position, if the parking position is within the sensing area, the system acquires sensing results from a roadside sensor and assists on-street parking using the sensing results from the roadside sensor, where the on-street parking assistance is automatic parking that does not require driving by an occupant ,
At least one processor
determining whether there is available parking near the destination;
If there is a parking space available near your destination, we will guide you to the parking space.
When there is no available parking space around the destination and on-street parking is necessary, acquiring available parking area data includes acquiring available parking area data including information on on-street parking spaces;
In suggesting parking locations, based on information about on-street parking spaces,
Suggests on-street parking locations to occupants .

In this manner, the sensing results of the roadside device can be used to assist vehicles wishing to park in smoothly parking on the street. In this way, vehicles wishing to park can effectively enjoy the parking assistance service.

Note that the symbols in parentheses included in the claims, etc., are intended to exemplify the correspondence with the parts of the embodiments described below, and are not intended to limit the technical scope.

FIG. 2 is a diagram showing the schematic configuration of a roadside unit and a vehicle. FIG. 2 is a diagram showing the functional configuration of a roadside unit and a vehicle. FIG. 10 is a diagram illustrating an example of a parking availability map. FIG. 10 is a diagram illustrating an example of a parking availability map. FIG. 10 is a diagram showing an example of display using a CID. FIG. 10 is a diagram showing an example of AR display by a HUD. 10 is a flowchart showing an example of processing by a roadside device. FIG. 2 is a diagram showing the functional configuration of a roadside unit and a vehicle. FIG. 10 is a diagram illustrating an example of a parking availability map. FIG. 1 is a diagram showing a schematic configuration of a reservation system. FIG. 2 is a diagram showing the functional configuration of a roadside unit and a cloud server. FIG. 2 is a diagram showing the functional configuration of a cloud server and a vehicle. FIG. 10 is a diagram showing an example of display using a CID. 10 is a flowchart showing an example of processing by a roadside device. FIG. 2 is a diagram showing the functional configuration of a roadside unit and a vehicle. FIG. 10 is a diagram showing an example of display using a CID. FIG. 1 is a diagram for explaining automatic parking using communication. 10 is a flowchart showing an example of processing by a vehicle.

Below, several embodiments will be described based on the drawings. Note that corresponding components in each embodiment will be given the same reference numerals, and duplicate explanations may be omitted. When only a portion of the configuration is described in each embodiment, the configuration of other previously described embodiments can be applied to the remaining portions of that configuration. Furthermore, in addition to the combinations of configurations explicitly stated in the description of each embodiment, configurations of multiple embodiments can also be partially combined together even if not explicitly stated, as long as there are no particular problems with the combination.

(First embodiment)
As shown in Fig. 1, the roadside device 1 of the first embodiment is a parking assistance device installed on a roadside. The roadside device 1 provides a local parking assistance service in a sensing area SA (described later). The roadside device 1 is sometimes called an RSU (Road Side Unit). The roadside device 1 may constitute part of a traffic infrastructure.

The roadside unit 1 can also be referred to as a V2I communication device that communicates with the vehicle 20. The roadside unit 1 may be configured to perform V2I (Vehicle-to-Infrastructure) communication between the vehicle 20 and the roadside unit 1. V2I communication is sometimes called road-to-vehicle communication. The architecture of V2X communication, including V2I communication, may be one of the architectures defined in ISO 21217, ETSI TS 102 940-943, IEEE 1609, etc. The roadside unit 1 can also be one element of an ITS (Intelligent Transport System). The roadside unit 1 is configured to include a processing unit 2, a communication circuit 3, roadside sensors 4, and a map database (hereinafter referred to as a map DB) 5.

The processing device 2 is primarily composed of a computer, for example. The computer constituting the processing device 2 may have at least one memory 2a and one processor 2b. The memory 2a may be at least one type of non-transient physical storage medium, such as semiconductor memory, magnetic media, or optical media, that non-temporarily stores programs and data that can be read by the processor 2b. Furthermore, the memory 2a may be provided with a rewritable volatile storage medium, such as RAM (Random Access Memory). The processor 2b includes at least one type of core, such as a CPU (Central Processing Unit), GPU (Graphics Processing Unit), or RISC (Reduced Instruction Set Computer)-CPU.

The communication circuit 3 is configured to be capable of V2I communication with the vehicle 20. The communication circuit 3 includes a modulation circuit, a demodulation circuit, and an amplification circuit. The communication circuit 3 modulates and amplifies messages provided by the processing device 2 and transmits them from the antenna 3a. The communication circuit 3 also demodulates and amplifies messages received via the antenna 3a and provides them to the processing device 2. The frequency used for communication may be, for example, the 5 GHz band or the 700 MHz band.

The roadside sensor 4 is configured to be able to sense a sensing area SA of the road RD surrounding the roadside unit 1. The roadside sensor 4 is fixedly installed with respect to the road RD. In order to achieve a wide sensing area SA or to reduce blind spots caused by obstacles, the roadside sensor 4 may be attached to the tip of a pole or a building. The sensing area SA is set in advance to include the road RD.

The roadside sensor 4 may be, for example, a camera, LiDAR (Light Detection and Ranging/Laser Imaging Detection and Ranging), imaging radar, etc. The roadside sensor 4 may also be configured as a combination of multiple types of sensors.

Map DB5 is primarily composed of a storage medium that non-temporarily stores computer-readable data. The storage medium may be at least one type of non-transient physical storage medium, such as semiconductor memory, magnetic media, or optical media.

Map DB5 stores a map of the road area including the sensing area SA. The map may include a parking availability map that stores distinguishable parking spaces SP1 and no-parking spaces SP0. The map stored in map DB5 may be a map containing dynamic information that can be updated by the processing device 2.

Vehicle 20 may be a vehicle capable of achieving autonomous driving at level 3 or higher as specified in SAE J3016. Vehicle 20 may also be a vehicle capable of achieving autonomous driving at level 1 or 2.

A vehicle 20 capable of autonomous driving level 1 or 2 may be a vehicle capable of performing driving assistance, in which an on-board system assists the driver in driving. Autonomous driving or driving assistance may include one or both of automatic parking, in which an on-board system automatically performs parking, and parking assistance, in which an on-board system provides auxiliary assistance to the driver in parking. Vehicle 20 may correspond to one or both of a vehicle requesting parking and an information providing vehicle.

An in-vehicle system is sometimes called an OBU (On-Board Unit). An in-vehicle system that performs autonomous driving is sometimes called an autonomous driving system. An in-vehicle system capable of V2X (Vehicle-to-Everything) communication with a roadside unit 1 and another vehicle, etc., can also be called a V2X communication device.

The vehicle 20 is configured to include a processing device 21, a communication circuit 22, an on-board sensor 23, a driving actuator 24, a display device 25, and an operation input device 26. Here, the processing device 21 and the communication circuit 22 may be included in an on-board system. At least one of the on-board sensor 23, the driving actuator 24, the display device 25, and the operation input device 26 may also be included in the on-board system.

The processing device 21 is, for example, an in-vehicle device primarily composed of a computer. The computer constituting the processing device 21 may have at least one memory 21a and one processor 21b. The memory 21a may be at least one type of non-transient physical storage medium, such as semiconductor memory, magnetic media, or optical media, that non-temporarily stores programs and data readable by the processor 21b. Furthermore, the memory 21a may be provided with a rewritable volatile storage medium, such as RAM (Random Access Memory). The processor 21b includes at least one type of core, such as a CPU (Central Processing Unit), GPU (Graphics Processing Unit), or RISC (Reduced Instruction Set Computer)-CPU.

The communication circuit 22 is configured to be capable of V2I communication with the roadside unit 1. Furthermore, the communication circuit 22 may be configured to be capable of V2V (Vehicle-to-Vehicle) communication with other vehicles. The communication circuit 22 includes a modulation circuit, a demodulation circuit, and an amplification circuit. The communication circuit 22 modulates and amplifies messages provided by the processing device 21 and transmits them from the antenna 22a. The communication circuit 22 also demodulates and amplifies messages received via the antenna 22a and provides them to the processing device 21. The frequency used for communication may be, for example, the 5 GHz band or the 700 MHz band.

The on-board sensor 23 is configured to be capable of sensing a sensing area SA around the vehicle 20. The on-board sensor 23 is, for example, a camera, LiDAR, laser radar, millimeter-wave radar, ultrasonic sonar, imaging radar, etc. The on-board sensor 23 may be a combination of multiple sensors or multiple types of sensors mounted on the vehicle 20 to sense the front, sides, and rear of the vehicle 20.

The driving actuator 24 is an actuator for driving the vehicle 20. Multiple driving actuators 24 of different types may be provided in the vehicle 20. A driving type driving actuator 24 is, for example, a power train including at least one of an internal combustion engine, an electric motor, etc. A braking type driving actuator 24 is, for example, a brake actuator. A steering type driving actuator 24 is, for example, a steering. The driving actuator 24 is configured to be controllable by, for example, the processing device 21.

The display device 25 displays information to the occupants, including the driver, of the vehicle 20. The display device 25 may be, for example, a graphic meter, a combination meter, a car navigation system, a CID (Center Information Display), or a HUD (Head-Up Display). The display device 25 may include a display capable of displaying images.

The operation input device 26 accepts operations by occupants, including the driver of the vehicle 20. The operation input device 26 may be an accelerator pedal, brake pedal, or steering wheel for operating the driving actuator 24 during manual driving. The operation input device 26 may also be a switch, lever, touch panel, etc. for transmitting the occupant's intentions to the processing device 21. The touch panel may be configured as an integral part of a display. The display device 25 and the operation input device 26 may be collectively referred to as an HMI (Human Machine Interface).

Next, using Figure 2, we will explain the functional configuration by which the roadside unit 1 realizes parking assistance services for the vehicle 20. The processing device 2 of the roadside unit 1 is configured to include a space determination unit 11, a map generation unit 12, and a space information transmission unit 13 as functional blocks realized by a processor 2b that executes a program.

In the roadside unit 1, the space determination unit 11 determines the on-street parking spaces in the sensing area SA of the roadside sensor 4. The space determination unit 11 determines whether the spaces that make up the sensing area SA are parking-prohibited or not. The space determination unit 11 determines that any area where parking is prohibited under the Road Traffic Act is a no-parking space SP0 without exception, and designates it as a no-parking space SP0.

The space determination unit 11 also obtains sensing results for the sensing area SA from the roadside sensor 4. The space determination unit 11 processes the sensing results and recognizes objects in the sensing area SA. For example, if an image is obtained as the sensing result, it is possible to recognize the object, including its type, using semantic segmentation. Also, for example, if a reflected signal of a pulse emitted by LiDAR is obtained as the sensing result, it is possible to recognize the object, including its distance, using a method such as TOF (Time Of Flight).

The space determination unit 11 designates an area of the sensing area SA where it determines through object recognition that a static object exists as a no-parking space SP0. If a dynamic object (e.g., a vehicle traveling on the road) is temporarily recognized, the area in which the dynamic object is recognized does not need to be designated as a no-parking space SP0. Whether an object is dynamic or static can be determined, for example, by whether the object is continuously recognized in the same position in the time-series data of the sensing results.

The space determination unit 11 may determine whether parking is possible for each segment obtained by dividing the sensing area SA. The segments to be determined may be virtual divisions of the sensing area SA in advance. The size of the segments may be set to conform to the official format for V2X communication. The size of the segments may be set appropriately based on considerations such as the computational processing load, communication load, or the reliability of the parking space output as a calculation result.

The sensing area SA may be divided into segments the size of a standard vehicle. The sensing area SA may be divided into matrix-shaped segments, for example, 1 m square. In this way, when the segments are set relatively large, the processing load and communication load due to increased data volume can be reduced. On the other hand, if even a part of a segment overlaps an area where parking is prohibited under the Road Traffic Act, the entire segment must be designated as a no-parking space SP0.

The sensing area SA may be divided into small segments of approximately 30 cm square. In this way, when the segments are set relatively small, it is possible to display road signs as the boundary between parking spaces SP1 and no-parking spaces SP0, and it is possible to display spaces with greater accuracy.

The map generation unit 12 generates a parking availability map that associates road map information previously stored in the map DB 5 with the judgment results of the space judgment unit 11. The parking availability map is a dynamic map that is updated each time the space judgment unit 11 makes a judgment. The map generation unit 12 stores the parking availability map based on the latest information in the map DB 5.

Figure 3 illustrates a visualized example of a parking availability map. Parking available spaces SP1 and parking unavailable spaces SP0 are associated with and superimposed on the sensing area SA of the road RD around the roadside unit 1.

Furthermore, the map generation unit 12 may add information regarding the cost of on-street parking to each parking available space SP1, as shown in FIG. 4. The cost may be calculated by the space determination unit 11 or the map generation unit 12. When the cost is mapped, a numerical value indicating the cost may be associated with each parking available space SP1. When the cost is mapped, the cost may be classified into multiple categories, such as low-cost spaces and high-cost spaces, and the categories may be associated with each parking available space SP1. In the example of FIG. 4, low-performance spaces SP11 corresponding to high costs and high-performance spaces SP12 corresponding to low costs are set as multiple categories.

The cost may be calculated based on parking history. The parking history may be based on the number of times on-street parking has actually been performed in that space. The parking history may be obtained by the roadside unit 1 accumulating sensing results from the roadside sensor 4. The parking history may be obtained from data provided by V2I communication from vehicles 20 parked in the sensing area SA.

For example, as shown in Figure 4, if there is a shrub PL on the side of the road, the parking record for the space adjacent to the shrub PL tends to be low even if parking is permitted. This is because the shrub PL gets in the way, making it difficult for occupants to get in and out of the vehicle 20.

The cost may be a cost imposed on a vehicle traveling on road RD. That is, the cost required for a vehicle traveling on road RD to avoid a parked vehicle may be calculated. For example, the amount of change in the traveling trajectory of a traveling vehicle to avoid a parked vehicle may be calculated as the cost. For example, the extra time taken by a traveling vehicle to avoid a parked vehicle may be calculated as the cost.

If the space determination unit 11 determines whether parking is possible for each segment, the map generation unit 12 may generate a parking possibility map with the same granularity as the segment. If the space determination unit 11 determines whether parking is possible for each segment, the map generation unit 12 may combine multiple segments into segments with coarser granularity and then generate a parking possibility map.

Here, consider a case where vehicles 20 in a city are a mixture of vehicles that support the first message format and vehicles that support the second message format. In this case, the map generation unit 12 may generate both a parking availability map expressed in segments that support the first message format and a parking availability map expressed in segments that support the second message format. In this way, information can be quickly provided to vehicles 20 that conform to each format.

The information on the judgment results by the space judgment unit 11 and the parking feasibility map generated by the map generation unit 12 and stored in the map DB 5 correspond to parking area data indicating areas where parking is possible.

The space information transmitter 13 transmits information about on-street parking spaces via V2I communication using the communication circuit 3 in response to a request from a vehicle approaching the sensing area SA and wishing to park on the street in the sensing area SA. The information about on-street parking spaces may be essentially the available parking area data itself, an excerpt of the available parking area data, or processed available parking area data.

In more detail, the information regarding on-street parking spaces may be the parking availability map itself, or information extracted from the parking availability map. The information regarding on-street parking spaces may simply be information indicating whether or not a parking available space SP1 exists in the sensing area SA. The information regarding on-street parking spaces may be incorporated into a predetermined message format and transmitted.

The processing device 21 of the vehicle 20 (particularly the vehicle requesting parking) is configured to include a transmission request unit 31, a space display unit 32, and an automatic parking unit 33 as functional blocks realized by a processor 21b that executes a program.

The transmission request unit 31 determines whether the destination of the vehicle 20 is within the sensing area SA of the roadside unit 1 or the vicinity of the sensing area SA, and whether on-street parking is planned in the vicinity of the destination. The destination may be, for example, a destination set by the occupant in the navigation system of the vehicle 20. The destination may be a destination set by the occupant for autonomous driving. The navigation system is a system that shows the driver the route to the destination of the vehicle 20.

When the vehicle is planning to park on the street near the destination, the transmission request unit 31 requests the roadside unit 1 corresponding to the sensing area SA to provide information about the on-street parking space upon approaching the sensing area SA. Approaching the sensing area SA here may mean approaching within a distance that allows V2I communication (e.g., direct communication using a single hop method) with the communication circuit 3 of the roadside unit 1.

When the roadside unit 1 receives the request, information about the on-street parking space is sent to the vehicle 20 as described above.

The space display unit 32 generates display content to be displayed on the display device 25 based on information regarding on-street parking spaces.

The display content may be content to be displayed as a real image on the CID as the display device 25. For example, as shown in Figure 5, the display content may be content DC1 displayed on the screen of the CID.

Specifically, the display content may be content DC1 that displays a bird's-eye view of the sensing area SA on the road RD. The display content may be in the form of an image showing the road RD, with an image of a parking space showing a parking space and an image showing a no-parking space superimposed on it.

The multiple available parking spaces may be selectively selected by the occupant operating the operation input device 26 (e.g., a touch panel integrated with the screen). The automatic parking unit 33, described below, will then automatically park the vehicle in the selected available parking space SP1.

The operation input device 26 may be able to switch between simple display content that clearly displays parking-allowed spaces SP1 and no-parking spaces SP0 as shown in FIG. 5, and display content that clearly displays low-performance spaces SP11 and high-performance spaces SP12 as shown in FIG. 4. In a display format similar to that shown in FIG. 4, even in a situation where multiple parking-allowed spaces SP1 exist, the driver can easily determine the space in which to park by referring to the cost (parking history).

The display content may be content DC2 that is displayed as a virtual image on the HUD as the display device 25. For example, as shown in Figure 6, the display content may be AR display content used for augmented reality (AR) display that is superimposed on the environment outside the vehicle.

Specifically, the display content may be configured to be superimposed on the road surface outside the vehicle. The display content may include an image indicating a parking space that is superimposed on a parking space on the road surface, and an image indicating a no-parking space that is superimposed on a no-parking space.

Similar to the real image display content in Figures 4 and 5, multiple parking spaces SP1 may be alternatively selectable by accepting operation of the operation input device 26 by the occupant. In this case, the operation input device 26 may be, for example, a steering switch.

The automatic parking unit 33 performs automatic parking in the parking space SP1 selected by the occupant. The automatic parking unit 33 calculates a driving trajectory from the current position of the vehicle 20 to the parking space SP1 selected by the occupant. The driving trajectory includes a trajectory for performing parallel parking, including turning. The automatic parking unit 33 determines the operation of the driving actuator 24 to realize the calculated driving trajectory and controls the driving actuator 24. In this way, the vehicle 20 is parked on the street by the on-board system.

Next, an example of a processing method for assisting on-street parking using the roadside unit 1 will be explained using the flowchart in Figure 7. The series of processes shown in steps S11 to S15 is started at predetermined time intervals or based on a predetermined trigger.

In S11, the roadside sensor 4 performs sensing of the sensing area SA. After processing S11, proceed to S12.

In S12, the space determination unit 11 performs a determination of whether the sensing area SA is an on-street parking space. After processing S12, proceed to S13.

In S13, the map generation unit 12 generates a parking availability map for the sensing area SA based on the determination by the space determination unit 11. After processing S13, proceed to S14.

In S14, the space information transmission unit 13 determines whether there is an information transmission request from a vehicle 20 approaching the sensing area SA. If the answer is Yes, proceed to S15. If the answer is No, the series of processes ends.

In S15, the space information transmission unit 13 transmits information about the on-street parking space to the vehicle 20 approaching the sensing area SA. This completes the series of processes.

According to the first embodiment described above, information regarding available spaces for on-street parking based on the sensing results of the roadside sensor 4 can be quickly provided to a vehicle 20 approaching the roadside unit 1 and wishing to park. Therefore, the roadside unit 1 can assist the vehicle 20 in smoothly parking on the street. In this way, a parking assistance service can be realized.

Furthermore, according to the first embodiment, the parking area data includes a parking availability map showing parking available spaces SP1 and parking unavailable spaces SP0. Because the map clearly shows parking available spaces SP1 and parking unavailable spaces SP0, the vehicle 20 can easily determine where to park on the street.

Furthermore, according to the first embodiment, the cost of on-street parking is calculated for the parking space SP1, and the parking space SP1 is further classified into multiple categories based on the cost. By referring to the classification, the vehicle 20 can easily determine the optimal location within the parking space SP1 for on-street parking.

In addition, according to the first embodiment, the information regarding on-street parking spaces includes data containing multiple segments obtained by dividing the sensing area SA into a matrix and information indicating whether parking is permitted or prohibited attached to each of the multiple segments. Because the data is constructed using segments, information regarding on-street parking spaces can be exchanged between devices in a general-purpose manner.

Second Embodiment
8 and 9, the second embodiment is a modification of the first embodiment. The second embodiment will be described, focusing on the differences from the first embodiment.

The roadside unit 1 of the second embodiment provides parking assistance services not only in the sensing area SA but also in an area that includes an extended sensing area ESA. The extended sensing area ESA is an area sensed by an on-board sensor 23 of an information providing vehicle 20a that provides information on sensing results to the roadside unit 1, and is an area excluding the sensing area SA of the roadside sensor 4. The information providing vehicle 20a may be a different vehicle from the parking requesting vehicle 20b, or may be the same vehicle. The roadside unit 1 may collect sensing results from multiple information providing vehicles 20a.

As shown in Figure 7, the processing device 21 of the vehicle 20 (particularly the information providing vehicle 20a) is configured to include a sensing result transmission unit 34 as a functional block realized by the processor 21b executing a program.

The sensing result transmission unit 34 acquires sensing results from the on-board sensor 23. If it is determined that the extended sensing area ESA obtained from the on-board sensor 23 is an area adjacent to the sensing area SA of the roadside unit 1, the sensing result transmission unit 34 decides to transmit information regarding the sensing results to the roadside unit 1.

The sensing result transmission unit 34 generates a message containing information about the sensing result based on the sensing result. This message may be, for example, a Collective Perception Message (CPM).

The space determination unit 11 in the roadside unit 1 determines the on-street parking spaces in the sensing area SA based on the sensing results obtained from the roadside sensor 4. Furthermore, the space determination unit 11 in the roadside unit 1 determines the on-street parking spaces in the extended sensing area ESA based on information regarding the sensing results received from the information providing vehicle 20a.

The map generation unit 12 generates a parking availability map (see Figure 9) for the sensing area SA and the extended sensing area ESA based on the determination results by the space determination unit 11. Based on this parking availability map, information regarding on-street parking spaces is provided to the vehicle 20b wishing to park.

In the second embodiment described above, the processing device 2 of the roadside unit 1 receives information about the sensing results from communication targets sensing the extended sensing area ESA outside the sensing area SA, including a vehicle 20a other than the vehicle 20b requesting parking, via the communication circuit 3. The processing device 2 then generates dynamic available parking area data by expanding it to include information about the extended sensing area ESA.

(Third embodiment)
10 to 12, the third embodiment is a modification of the first embodiment. The third embodiment will be described, focusing on the differences from the first embodiment.

In the third embodiment, as shown in FIG. 10 , multiple roadside units 1, which are the roadside units 1 shown in the first embodiment and installed at locations separated from each other, are configured to be able to communicate with a cloud server 41, for example, by being connected to the Internet. In addition to the local parking assistance service of the first embodiment, each roadside unit 1 cooperates with the cloud server 41 to provide a road parking space reservation service to a vehicle 20. The multiple roadside units 1 and the cloud server 41 constitute a reservation system 40.

The cloud server 41 is a remote center that aggregates and manages reservation information. The cloud server 41 is connected to the Internet, for example, and is therefore capable of communicating with multiple roadside units 1 over a wide area and with vehicles 20 over a wide area. Communication between the cloud server 41 and vehicles 20 may be referred to as V2N (Vehicle-to-Network) communication or V2C (Vehicle-to-Cloud) communication.

The cloud server 41 collects local data from each roadside unit 1. The cloud server 41 integrates the local data and provides integrated data to each vehicle 20. The cloud server 41 accepts reservations from each vehicle 20. The cloud server 41 provides reservation information for each vehicle 20 to each roadside unit 1.

The cloud server 41 refers to a server on a network realized by cloud computing. The cloud server 41 is configured to include at least one processing device 42 and a map DB 43.

In the reservation system 40, the cloud server 41 may be realized by a single processing device 42, or by multiple processing devices 42 linked to each other. The multiple processing devices 42 may be located in remote locations separated from each other. The processing device 42 may be realized primarily by a computer.

The computer constituting the processing device 42 may have at least one memory 42a and one processor 42b. The memory 42a may be at least one type of non-transient tangible storage medium, such as semiconductor memory, magnetic media, or optical media, that non-temporarily stores programs and data that can be read by the processor 42b. Furthermore, the memory 42a may be provided with a rewritable volatile storage medium, such as RAM (Random Access Memory). The processor 42b includes at least one type of core, such as a CPU (Central Processing Unit), GPU (Graphics Processing Unit), or RISC (Reduced Instruction Set Computer)-CPU.

Map DB43 is primarily composed of a storage medium that non-temporarily stores computer-readable data. The storage medium may be at least one type of non-transient physical storage medium, such as semiconductor memory, magnetic media, or optical media.

Map DB 43 stores a wide-area parking availability map that aggregates the local parking availability maps stored in map DB 5 of each roadside unit 1. For this reason, it is preferable that the storage capacity of map DB 5 of cloud server 41 be larger than the storage capacity of map DB 5 of each roadside unit 1.

The map DB 43 may further store reservation information associated with each space on the parking availability map. The reservation information may include information about the vehicle 20 to be reserved (e.g., vehicle ID, information about the vehicle size), the reservation time, etc.

Next, the functional configuration for the reservation system 40 to provide parking assistance services to a vehicle 20 (e.g., a vehicle requesting parking) will be explained using Figures 11 and 12. The processing device 2 of the roadside unit 1 includes a space determination unit 11, a map generation unit 12, and a local data transmission unit 14 as functional blocks realized by a processor 2b that executes a program.

In addition to the functions of the first embodiment, the space determination unit 11 reflects reservation information provided by the cloud server 41 in determining whether or not parking is permitted for on-street parking spaces. Specifically, the space determination unit 11 designates spaces for which parking reservations have been made as no-parking spaces SP0. As in the first embodiment, the map generation unit 12 updates the parking permit map for the sensing area SA to the latest version. This local parking permit map is stored in the map DB 5.

The local data transmission unit 14 transmits local data, i.e., information regarding local on-street parking spaces, to the cloud server 41. Specifically, the local data transmission unit 14 transmits the latest parking availability map stored in the map DB 5 to the cloud server 41. By configuring the transmission of the parking availability map, the amount of data transmitted can be reduced compared to transmitting the sensing results of the roadside sensors 4 to the cloud server 41, thereby reducing the processing load on the cloud server 41.

The processing device 42 of the cloud server 41 is configured to include a map integration unit 51, an integrated data transmission unit 52, a reservation reception unit 53, and a reservation information transmission unit 54 as functional blocks realized by a processor 42b that executes a program.

The map integration unit 51 integrates the local parking availability maps provided by each roadside unit 1. The integrated map (hereinafter referred to as the integrated map) is a wide-area parking availability map. For example, adjacent roadside units 1 are arranged so that their sensing areas SA are not far apart, for example, so that the ends of their sensing areas SA overlap. In this case, the integrated map can cover on-street parking spaces in a wide, continuous area. The map integration unit 51 stores the integrated map based on the latest information in the map DB 43.

In response to receiving an integrated data request for a reservation from a vehicle 20, the integrated data transmission unit 52 transmits integrated data to the vehicle 20. The integrated data is, for example, the latest integrated map stored in the map DB 43. When information regarding the destination of the vehicle 20 is received in the data request from the vehicle 20, the data transmitted by the cloud server 41 may be excerpted data from the integrated map that extracts information about the area around the destination.

The reservation reception unit 53 accepts reservations from the vehicle 20. The reservation reception unit 53 may accept a space directly specified by the vehicle 20 as a reserved space. The reservation reception unit 53 may also accept a specification of a desired parking area from the vehicle 20 and select the optimal reserved space from within the desired parking area.

In response to receiving a reservation, the reservation information transmission unit 54 transmits reservation information to the roadside unit 1 that is in charge of the reserved space. The reservation information transmission unit 54 may request that the roadside unit 1 respond that the reservation has been successfully processed.

When a response is received from the roadside unit 1, the reservation reception unit 53 may reflect the reservation information in the map DB 5 of the roadside unit 1. Furthermore, the reservation information transmission unit 54 may notify the vehicle 20 that the reservation has been processed successfully.

The processing device 21 of the vehicle 20 is configured to include a data request unit 35, a space display unit 32, and a reservation request unit 36 as functional blocks realized by the processor 21b that executes a program.

The data request unit 35 requests the cloud server 41 to send data for determining the on-street parking space to be reserved. The trigger for the request by the data request unit 35 may be, for example, an operation of the operation input device 26 by the driver of the vehicle 20, i.e., an expression of intent to make a reservation. On the other hand, when the vehicle 20 is in autonomous driving, the autonomous driving system may trigger the data request without the driver's expression of intent.

Here, the reservation should be made when the vehicle 20 is far away from the destination, rather than after the vehicle 20 approaches the sensing area SA around the destination as in the first embodiment. This allows the reservation function of the reservation system 40 to be utilized more effectively.

When data is provided from the cloud server 41 in response to a data request, the space display unit 32 displays information based on the data on the display device 25. If the provided data is an integrated map, the space display unit 32 generates display content similar to that of the first embodiment. However, the display content of the third embodiment may include a parking availability map of a relatively wide area that includes the destination, as shown in FIG. 13.

In the first embodiment, the vehicle 20 was immediately parked in the selected parking space SP1 from among the parking spaces SP1 displayed by the display device 25, but in the third embodiment, the selected parking space SP1 is reserved.

When a parking space SP1 is selected by the driver (or the autonomous driving system), the reservation request unit 36 requests the cloud server 41 to reserve the parking space.

In the third embodiment described above, the cloud server 41 consolidates data collected from multiple roadside units 1, transmits it to the vehicle 20, and shares the reservation request of the vehicle 20 with the roadside unit 1. By providing a reservation service in cooperation with the roadside unit 1 and the cloud server 41, a vehicle 20 wishing to park can secure a parking spot on the road. In this way, the quality of the parking assistance service can be improved.

(Fourth embodiment)
14, the fourth embodiment is a modification of the first or third embodiment. The fourth embodiment will be described, focusing on the differences from the first or third embodiment.

In the fourth embodiment, the parking availability map generated by the map generation unit 12 includes information on parking history. Here, an example of a processing method for generating a parking availability map including information on parking history is explained in detail using the flowchart in Figure 14.

In S101, the map generation unit 12 stores a road map containing road information in the map DB 5. The road information may be downloaded from a road map server that distributes road maps, or may be downloaded from the cloud server 41 of the reservation system 40 as described in the third embodiment. The map generation unit 12 may periodically download road information and update the road information in the map DB 5 to the latest information. After processing S101, proceed to S102.

In S102, the map generation unit 12 adds areas where parking is prohibited under the Road Traffic Act as information on no-parking spaces SP0 to the road map stored in the map DB 5. After processing S102, proceed to S103.

In S103, when on-street parking is performed in a space other than the no-parking space SP0, the map generation unit 12 adds or updates on-street parking history information for the space where the on-street parking occurred and records it in the map DB5. Here, the on-street parking history information may be the cumulative number of on-street parking occurrences for the target space. The on-street parking history information may also be the number of on-street parking occurrences for a specified period of time, in other words, the frequency of on-street parking. After processing S103, proceed to S104.

In S104, the space determination unit 11 or the map generation unit 12 calculates the cost required for a vehicle traveling on road RD to avoid a vehicle 20 parked on the road and detour along the road. The map generation unit 12 records information on the cost required for the avoidance in the map DB 5 as the adverse impact caused by the vehicle 20 parked on the road. Information on the adverse impact may be included in information on the history of on-street parking. After processing S104, the process proceeds to S105.

In S105, the space determination unit 11 or the map generation unit 12 evaluates the parking-allowed space SP1 using the on-street parking record information recorded in the map DB 5. The evaluation here may involve calculating the cost of on-street parking for the parking-allowed space SP1. S105 ends the series of processes.

According to the fourth embodiment described above, when on-street parking occurs in the sensing area SA, information on on-street parking history is added to the parking availability map. Since the on-street parking history is updated sequentially, the reliability of the parking availability map can be improved.

Fifth Embodiment
15 to 18, the fifth embodiment is a modification of the fourth embodiment. The fifth embodiment will be described focusing on the differences from the fourth embodiment. Note that in the fifth embodiment, as in the second embodiment, the roadside unit 1 receives information provided by the information providing vehicle 20a and generates a map for the extended sensing area ESA as well.

As shown in Figure 15, the processing device 21 of the vehicle 20 (particularly the vehicle 20b requesting parking) is configured to include a destination surrounding area information search unit 37, a parking request unit 38, a parking position determination unit 39, and an automatic parking unit 33 as functional blocks realized by the processor 21b executing a program.

The destination surrounding area information search unit 37 searches for information about the area around the destination. Information about the area around the destination includes information about parking lots around the destination. Here, the area around the destination may be within walking distance of the destination, and is pre-set to, for example, a range of 500 m or 1 km from the destination. The destination surrounding area information search unit 37 further determines whether there are any available parking lots around the destination.

If the destination surroundings information search unit 37 determines that there are no available parking spaces around the destination, i.e., if on-street parking is necessary, the parking request unit 38 requests information about on-street parking spaces from roadside units 1 around the destination. This parking request may be a direct request to the roadside unit 1 if the vehicle 20 is already close enough to communicate with the roadside unit 1. If the vehicle 20 is far from the destination, this parking request may be replaced with a reservation request to the reservation system 40, i.e., a request to the cloud server 41.

The parking position determination unit 39 determines the parking position of the vehicle 20. Specifically, when the parking position determination unit 39 receives information about on-street parking spaces from the roadside device 1, it selects the optimal parking position from among the parking-available spaces SP1 based on information about past on-street parking and the size of the vehicle 20, etc. It then proposes this optimal parking position to the driver. If the driver accepts the proposal, the parking position determination unit 39 begins guiding the driver to the parking position.

If the driver's consent is not obtained, the parking position determination unit 39 displays a list of available parking spaces SP1 on the display device 25 and accepts the driver's selection of a parking position. Once the driver selects a parking position, the parking position determination unit 39 begins guiding the driver to that parking position.

The suggestions or list displayed to the driver may be, for example, a parking availability map like the one shown in Figure 16, with an image showing the destination or an image showing the optimal parking location superimposed on it.

The start of guidance to a parking location may be the start of on-street parking assistance if the vehicle 20 is already close enough to the roadside unit 1 to communicate with it. On-street parking assistance is a concept that includes both automatic parking that does not require the driver to drive and auxiliary assistance to the driver's driving behavior. Furthermore, the start of guidance to a parking location may be the start of route guidance to the parking location using the navigation system if the vehicle 20 is far from the destination. At the same time, a reservation of a space corresponding to the parking location may be made in the reservation system 40.

The automatic parking unit 33 performs automatic parking at the parking position determined by the parking position determination unit 39. Here, if the parking position is included in the sensing area SA of the roadside unit 1, the sensing results of the roadside sensor 4 provided by the roadside unit 1 can be used for automatic parking. Specifically, using the sensing results of the roadside sensor 4, the automatic parking unit 33 optimizes the actual parking position to a position that will cause the least inconvenience to passing vehicles.

At this time, the automatic parking unit 33 may communicate with another vehicle 20c that is parked on the road adjacent to the parking position, as shown in FIG. 17. For example, the automatic parking unit 33 may receive sensing results from the on-board sensor 23c of the other vehicle 20c and use the sensing results to optimize the actual parking position. This makes it possible to minimize the distance between the other vehicle 20c and the other vehicle 20c more safely.

The processing device 2 of the roadside unit 1 is configured to include a space determination unit 11, map generation unit 12, and space information transmission unit 13, similar to those in the first embodiment, as well as a parking assistance unit 15, as a functional block realized by a processor 2b that executes a program.

When the parking position is included in the sensing area SA of the roadside unit 1, the parking assistance unit 15 provides the sensing results of the roadside sensor 4 to the vehicle 20. This allows the parking position determined by the automatic parking unit 33 to be optimized, as described above.

Next, an example of a processing method for on-street parking by the processing device 21 of the vehicle 20 using information from the roadside unit 1 will be explained using the flowchart of Figure 18.

In S201, the destination surrounding area information search unit 37 searches for information about the surrounding area of the destination. After processing S201, proceed to S202.

In S202, the destination surrounding area information search unit 37 determines whether there is a vacant and available parking lot near the destination. If the answer is Yes, proceed to S203. If the answer is No, proceed to S204.

In S203, guidance to the parking lot begins using the navigation system. S203 marks the end of this series of processes.

In S204, the parking position determination unit 39 determines the optimal on-street parking space. After processing S204, proceed to S205.

In S205, the parking position determination unit 39 suggests an optimal parking position to the driver. Specifically, the parking position determination unit 39 causes the display device 25 to display the parking position. After processing S205, the process proceeds to S206.

In S206, the parking position determination unit 39 determines whether the proposal has been accepted by the driver. If yes, proceed to S207. If no, proceed to S208.

In S207, the parking position determination unit 39 begins guiding to the agreed parking position. After processing S207, proceed to S209.

In S208, the parking position determination unit 39 displays a list of parking spaces SP1 on the display device 25 and prompts the driver to select a parking position. After the selection, the parking position determination unit 39 processes S208 and then proceeds to S209.

In S209, the parking position determination unit 39 determines whether the determined parking position is within the sensing area SA of the roadside unit 1. If the answer is Yes, it requests parking assistance from the roadside unit 1 and proceeds to S211. If the answer is No, it proceeds to S210.

In S210, the parking position determination unit 39 displays the determined parking position on the display device 25. The determined parking position may be displayed, for example, superimposed on a road map of the navigation system. The series of processes ends with S210.

In S211, the parking position determination unit 39 determines whether automatic parking is possible for on-street parking. If the answer is Yes, proceed to S212. If the answer is No, proceed to S213.

In S212, the automatic parking unit 33 performs automatic parking using the sensing results transmitted from the roadside unit 1. The series of processes ends with S212.

In S213, the driver's parking behavior is assisted using the display on the display device 25. Here, the sensing results transmitted from the roadside unit 1 or the object recognition information analyzed using the sensing results are displayed on the display device 25. The series of processes ends with S213.

According to the fifth embodiment described above, the sensing results of the roadside unit 1 can be used to assist the vehicle 20b wishing to park in smoothly parking on the road. In this way, the vehicle 20b wishing to park can effectively enjoy the parking assistance service.

(Other embodiments)
Although multiple embodiments have been described above, the present disclosure should not be construed as being limited to those embodiments, and can be applied to various embodiments and combinations within the scope that does not deviate from the gist of the present disclosure.

Specifically, approaching the sensing area SA may mean approaching to a distance where direct communication using a multi-hop method is possible, in V2I communication between the communication circuit 22 of the vehicle 20 and the communication circuit 3 of the roadside unit 1.

Instead of the processing device 2 on the roadside unit 1 side, the processing device 21 on the vehicle 20 side may calculate the cost of on-street parking. In this case, the processing device 21 may acquire or analyze information on the driver's driving proficiency and reflect that proficiency in the cost.

In the second embodiment, the roadside unit 1 may communicate with other roadside units, obtain sensing results of the sensing areas of the roadside sensors of the other roadside units, and generate a parking feasibility map of the extended sensing area ESA based on this.

The control unit and method described herein may be implemented by a special-purpose computer comprising a processor programmed to perform one or more functions embodied in a computer program. Alternatively, the device and method described herein may be implemented by a special-purpose hardware logic circuit. Alternatively, the device and method described herein may be implemented by one or more special-purpose computers configured by a combination of a processor executing a computer program and one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory tangible storage medium.

(Disclosure of technical ideas)
This specification discloses multiple technical ideas described in the following multiple clauses. Some clauses may be written in a multiple dependent form, where the subsequent clause alternatively refers to the preceding clause. These multiple dependent clauses define multiple technical ideas.

(Technical thought 1)
A roadside device that is installed on a roadside and supports on-street parking of a vehicle (20, 20b),
A roadside sensor (4) that senses a sensing area (SA) of a road (RD) around the installation location;
at least one processor (2b) for generating dynamic parking availability data in the sensing area;
A storage medium (5) for storing the available parking area data;
a communication circuit (3) for V2I communication with the vehicle,
The at least one processor
A roadside device configured to cause the communication circuit to transmit information regarding on-street parking spaces based on the available parking area data to a vehicle that approaches the sensing area and wishes to park on the street in the sensing area.

(Technical thought 2)
The at least one processor
receiving, via the communication circuit, information on a sensing result from a communication target that senses an extended sensing area (ESA) outside the sensing area, the extended sensing area including at least one of a vehicle (20b) other than the vehicle requesting parking and another roadside device;
and generating the dynamic available parking area data by expanding the available parking area data to include information about the expanded sensing area.

(Technical thought 3)
The roadside device according to Technical Idea 1 or 2, wherein the parking area data includes a parking availability map indicating parking available spaces (SP1) and parking unavailable spaces (SP0).

(Technical thought 4)
The at least one processor
The roadside device according to Technical Idea 3 is further configured to calculate the cost of on-street parking for the parking-allowed spaces and classify the parking-allowed spaces into a plurality of categories according to the cost.

(Technical Thought 5)
The at least one processor
The roadside device according to Technical Idea 3 or 4 is further configured to add information about on-street parking records to the parking availability map when on-street parking is performed in the sensing area.

(Technical Thought 6)
A roadside device described in any one of Technical Ideas 1 to 5, wherein the information regarding the on-street parking space includes data including a plurality of segments obtained by dividing the sensing area into a matrix and information regarding whether parking is permitted or not attached to each of the plurality of segments.

Claims (4)

An on-board device that is mounted on a vehicle (20, 20b), has at least one processor (21b) for executing a process for assisting on-street parking of the vehicle, and is capable of communicating with a roadside device (1) that is installed on the roadside and has a roadside sensor (4) that senses a sensing area (SA) of a road surrounding an installation location,
The at least one processor
acquiring dynamic available parking area data from the roadside device or a server (41) that collects information from the roadside device;
Proposing a parking position to an occupant of the vehicle based on the available parking area data;
When the proposed parking position is accepted, if the parking position is within the sensing area, the system acquires a sensing result from the roadside sensor, and supports on-street parking using the sensing result from the roadside sensor.
The on-street parking assistance is automatic parking that does not require a driver to drive,
The at least one processor
and determining whether there is available parking near the destination.
If there is a parking lot available near the destination, provide information about the parking lot.
When there is no available parking lot around the destination and on-street parking is necessary, acquiring the available parking area data includes information on on-street parking spaces;
In suggesting the parking position, based on the information about the on-street parking space,
An in-vehicle device that suggests the parking position to the occupant as the on-street parking position . The at least one processor
The on-board device according to claim 1, further configured to use the sensing results to select a location where the on-street parking is actually performed during the automatic parking operation that is less likely to cause inconvenience to passing vehicles. The vehicle is configured to be able to communicate with another vehicle (20c) parked on the road adjacent to the parking position,
The at least one processor
2. The on-board device according to claim 1, further configured to acquire sensing results of an on-board sensor (23c) of the other vehicle, and to use the sensing results of the other vehicle to optimize the location where the on-street parking will actually be performed in the automatic parking. The at least one processor
2. The in-vehicle device according to claim 1, further configured to, based on the fact that the proposed parking position has not been accepted, display a list of available parking spaces (SP1) in the available parking area data on a display device (25) of the vehicle, and accept an operation to select the parking position from the occupant.