System and method for activating intelligent parking availability functions

Abstract

To provide a system and a method for identifying available parking spaces in congested zones.SOLUTION: A method according to one embodiment includes estimating, in response to receiving trajectory information about movement of a searching vehicle, a search time spent by the vehicle searching for parking in a given location. The method includes totaling, when the search time meets a time threshold, the search time with observed times associated with an additional entities parking in the location. The method includes updating a parking map according to the observed times when the observed times meet a parking threshold indicating a lack of available parking lots in the location. The parking map identifies active areas where parking is currently lacking. The method includes providing the parking map including the active areas to identified vehicles in proximity to locations associated with the active areas.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The content described in this specification generally relates to improving the identification of parking availability, particularly tracking the parking activities of a vehicle to identify active regions with a shortage of parking, and selectively activating the parking availability function of the vehicle within the active regions.

Background Art

[0002] Parking a vehicle in a particularly congested urban area can be a time-consuming task. For example, a driver often struggles to find parking without knowledge of whether parking within a given location is available. That is, the vehicle may proceed to a destination without knowing about the parking availability at the destination, including entering a parking garage, parking lot, etc. without knowing whether the destination contains available spots. Still, if such a parking location is close to full, it can be seen that finding an available spot is a time-consuming task of searching for an available spot. This is generally not preferable. Therefore, attempting to park in a congested area can be time-consuming and generally inefficient as the driver searches around parking garages and other locations to find an available parking space.

Summary of the Invention

[0003] In various embodiments, examples of systems and methods relate to modes that improve the identification of available parking spaces by better tracking parking availability through selective activation of parking availability tracking in connected vehicles. As previously mentioned, finding parking can be a time-consuming task, and as a result, when trying to find an available space in a busy area, it can delay the driver's arrival and cause driver frustration. Some parking garages and parking lots may include infrastructure-based systems for identifying available parking spots, but such systems are generally costly and complex to install and maintain. Furthermore, connected vehicles can scan parking areas to identify available parking spots to a cloud-based system that communicates with vehicles seeking parking, but when connected vehicles continuously provide such functionality, they consume considerable resources (e.g., computing resources, energy, communication bandwidth, etc.).

[0004] Accordingly, in one or more embodiments, a method is disclosed for improving the identification of available parking spaces by better aggregating the resources of connected vehicles in areas where available parking is scarce. For example, in at least one array, the parking system acquires information about vehicles driving around a geographic area. Roughly speaking, the information includes at least rough trajectory data along with location information about the movement of the vehicles. Naturally, in further arrays, the information may include additional data such as telematics data indicating more specific forms of vehicle operation (e.g., vehicle on / off, operating conditions, speed, etc.).

[0005] In either case, the parking system receives the above information from vehicles moving around a geographical area and analyzes the information to identify locations where available parking is scarce. The parking system can make this determination by deriving the parking search time from the trajectory information. In one embodiment, the parking system analyzes the information to identify when a vehicle begins searching for a parking spot and when it stops. The parking system can use various identification characteristics depending on the specific patterns presented by the vehicle. For example, in one approach, the parking system uses the point in time when the vehicle is within a predetermined distance from its destination, while in another approach, the parking system identifies the start time from when the vehicle enters a parking garage / lot, or when the vehicle's movement exhibits a turning pattern. In addition, in one approach, the parking system determines the end time by determining when the vehicle stops moving for a set time (e.g., 10 minutes). In a further approach, the parking system determines the end time according to the vehicle's off-event, such as shifting the transmission to parking.

[0006] Therefore, the parking system can determine whether a time threshold indicating difficulty in parking (e.g., >10 minutes) is met. If it is, the parking system can aggregate the search time as parking events for the associated location. The parking system can then check whether a particular location meets the parking threshold. The parking threshold indicates whether parking at that location reaches the number of available spots that can be considered difficult to park at that location. For example, to avoid suspicious events and enable proper characterization of locations, the parking threshold may indicate the number of parking events in a sliding time frame or the average parking search time in a sliding frame.

[0007] Therefore, when the parking system determines that a location meets the parking threshold, it updates the active area of ​​the parking map in one or more arrays and provides the parking map to connected vehicles within a given geographic area. In this way, when an area is active in the parking map, connected vehicles within the active area enable the parking identification function. The parking identification function generally involves activating sensors in the connected vehicle to scan for available parking spaces, which consumes additional resources. However, since the parking system limits the activation of the parking identification function to the active area, connected vehicles can better consolidate resources and avoid wasting resources by keeping the function continuously available. In either case, connected vehicles can communicate the location of available parking to the parking system, and the parking system shares this information with other vehicles to make parking easier in congested zones / locations. In this way, the parking system improves the identification of parking availability by consolidating resources in areas where additional parking information is needed.

[0008] A parking system for improving the identification of available parking spaces in a congested zone is disclosed according to one embodiment. The parking system includes one or more processors and a memory communicably coupled to one or more processors. The memory stores a control module that, when executed by one or more processors, causes one or more processors to estimate the search time spent by a search vehicle searching for parking at a given location in response to the receipt of trajectory information relating to the movement of the search vehicle. The control module includes instructions for summing observation time and search time, associated with additional entities parking at that location when the search time meets a time threshold. The control module includes instructions for updating a parking map according to observation time when the observation time meets a parking threshold indicating a shortage of available parking at that location. The parking map identifies active areas where parking is currently lacking. The control module includes instructions for providing a parking map including the active areas to identified vehicles adjacent to locations associated with the active areas.

[0009] Disclosed in one embodiment is a non-temporary computer-readable medium that improves the identification of available parking spaces in a congested zone and includes instructions that cause one or more processors to perform one or more functions when executed by one or more processors. The instructions include instructions for estimating the search time spent by a search vehicle searching for parking at a given location in response to the receipt of trajectory information relating to the movement of a search vehicle. The instructions include instructions for summing the observed time and the search time, associated with additional entities parking at that location when the search time meets a time threshold. The instructions include instructions for updating the parking map according to the observed time when the observed time meets a parking threshold indicating a shortage of available parking at that location. The parking map identifies active areas where parking is currently lacking. The instructions include instructions for providing the parking map, including the active areas, to identified vehicles adjacent to locations associated with the active areas.

[0010] In one embodiment, a method for improving the identification of available parking spaces in a congested zone is disclosed. In one embodiment, the method includes estimating the search time spent by a vehicle searching for parking at a given location in response to receiving trajectory information relating to the movement of a searching vehicle. The method includes summing the observed time and the search time associated with additional entities parking at that location when the search time meets a time threshold at that location. The method includes updating the parking map according to the observed time when the observed time meets a parking threshold indicating a shortage of available parking at that location. The parking map identifies active areas where parking is currently insufficient. The method includes providing the parking map containing the active areas to identified vehicles approaching locations associated with the active areas. [Brief explanation of the drawing]

[0011] The accompanying drawings incorporated herein and forming part thereof illustrate various systems, methods, and other embodiments of the present disclosure. The boundaries of the illustrated elements (e.g., boxes, groups of boxes, or other shapes) should be understood to represent one embodiment of the boundary. In some embodiments, one element may be designated as multiple elements, or multiple elements may be designated as one element. In some embodiments, an element shown as an internal component of another element may be realized as an external component, and vice versa. Furthermore, elements may not be shown to scale.

[0012] [Figure 1] This figure illustrates one embodiment of a vehicle in which the systems and methods disclosed herein can be implemented. [Figure 2] This figure illustrates one embodiment of a parking system that improves the identification of available parking spaces by selectively activating connected vehicles located in areas with low potential for use. [Figure 3] This is a diagram of a parking system within a cloud computing environment. [Figure 4] This flowchart illustrates one embodiment of a method associated with identifying active areas with insufficient parking and updating the parking map accordingly. [Figure 5] This flowchart illustrates one embodiment of selectively analyzing parking locations in terms of usability. [Figure 6] This figure shows a parking map divided into smaller regions, each containing multiple active areas. [Figure 7] This is a diagram of a parking map divided according to clustering. [Modes for carrying out the invention]

[0013] This invention discloses a system, method, and other embodiments associated with a mode for improving the identification of available parking spaces by better tracking parking availability through the selective activation of a parking availability function in a connected vehicle. As previously described, finding parking can be a time-consuming task. For example, attempting to park in a nearly full parking garage can seem impossible when there are no instructions on where available spaces are located. Similarly, finding street parking in a busy area can be a frustrating task, especially given the traffic that moves through the area in an even more complicated manner. As a result, drivers may become frustrated and spend a considerable amount of time searching for parking.

[0014] Some parking garages and parking lots have infrastructure-based systems to identify available spots, but such systems are generally expensive, complex to install and maintain, and do not solve the problems associated with on-street parking. Furthermore, while connected vehicles can scan parking areas to identify available parking spots, they consume a significant amount of resources (e.g., computing resources, energy, communication bandwidth, etc.) when continuously providing functions involving active monitoring by machine perception, which is generally undesirable, especially if those resources could otherwise be diverted to improve safety or other vehicle functions.

[0015] Therefore, in various configurations, the disclosed systems and methods improve the identification of available parking spaces by concentrating resources on connected vehicles in areas where available parking is scarce, rather than broadly sensing availability without considering resource usage. For example, in at least one configuration, the parking system acquires information about vehicles driving around a given geographic area. Roughly speaking, acquiring information involves less involvement (i.e., less resource concentration) than actively monitoring a given area using a clear parking availability function within the vehicle. For example, the information includes at least rough trajectory data along with location information about the vehicle's movement. Naturally, in further configurations, the information may include additional data such as telematics indicating more specific forms of vehicle operation (e.g., vehicle on / off, operating conditions, speed, etc.).

[0016] In either case, the parking system receives the above information from vehicles moving within a given geographical area and analyzes the information to identify areas where available parking is scarce, so that the parking system can determine whether or not to activate the relevant area for the use of a more robust parking availability function. The parking system can make this determination by deriving the parking search time from the trajectory information. The parking search time generally characterizes how long an individual vehicle spends searching for a parking spot. In one embodiment, the parking system analyzes the information to identify when a vehicle begins searching for a parking spot and when it ends its search. The parking system can use various identification characteristics depending on the specific pattern presented by the vehicle. For example, in one approach, the parking system uses the point in time when the vehicle is within a predetermined distance of the destination, while in another approach, the parking system identifies the start time from when the vehicle enters a parking garage / lot, or when the vehicle's movement begins to trace a turning pattern. Furthermore, the parking system determines the end time by determining when the vehicle has stopped moving for a set period of time (e.g., 10 minutes) in one approach. In a further approach, the parking system determines the end time according to an off-event of the vehicle, such as shifting the transmission to parking.

[0017] Therefore, instead of wasting resources by having vehicles continuously perform more complex parking identification functions, the parking system can determine the search time in a given area and use the search time as an indicator of parking congestion. If the search time meets a threshold, the parking system can aggregate the search time as parking events for the relevant locations. The parking system can then perform additional checks to determine whether a particular location meets a parking threshold. The parking threshold indicates whether parking at that location can be considered difficult or congested. For example, to avoid spurious events and enable proper characterization of locations, the parking threshold indicates the number of parking events within a sliding time frame.

[0018] Therefore, when the parking system determines that a location meets the parking threshold, it updates the active area of ​​the parking map in one or more arrays to provide the parking map to connected vehicles within a given geographic area. In this way, when a given area is active in the parking map, connected vehicles within the active area enable the parking identification function. The parking identification function generally involves activating sensors in the connected vehicle to actively scan for available parking spaces by processing sensor data using various perceptual algorithms (e.g., object detection and classification algorithms) that consume additional resources. However, since the parking system limits the activation of the parking identification function to vehicles within the active area, connected vehicles can better consolidate resources and avoid wasting resources by continuously enabling this function in areas where parking is easy and they are unlikely to benefit from this additional functionality. In either case, connected vehicles can then communicate the location of available parking to the parking system, which shares this information with other vehicles to make parking easier in congested areas. In this way, the parking system improves the identification of parking availability by selectively concentrating resources in areas where additional parking information is required.

[0019] Figure 1 shows an embodiment of Vehicle 100. As used herein, “Vehicle” refers to any form of powered transport equipment. In one or more embodiments, Vehicle 100 is an automobile. While the arrangement will be described herein in relation to automobiles, it should be noted that embodiments are not limited to automobiles. In some embodiments, Vehicle 100 can be any device for transporting passengers, for example. In various approaches, Vehicle 100 can be an automated vehicle. As used herein, an automated vehicle means a vehicle with at least some autonomous driving capabilities. Thus, Vehicle 100 can operate autonomously, semi-autonomously, or with the assistance of various advanced driver-assistance systems (ADAS). Furthermore, Vehicle 100 is generally an connected vehicle that can communicate wirelessly with other equipment, infrastructure elements (e.g., roadside units), cloud computing elements, etc., such as other connected vehicles. Furthermore, while this disclosure generally describes the vehicle 100, in yet another approach, the systems and methods disclosed herein are not associated with any particular mode of transport and instead can be implemented as part of other entities, such as electronic devices embedded as part of mobile electronic equipment that can be carried by an individual and function independently or in cooperation with additional systems (e.g., sensors) of other equipment.

[0020] In all cases, the vehicle 100 includes various elements. In various embodiments, the vehicle 100 does not need to have all of the elements shown in Figure 1. The vehicle 100 can have any combination of the elements shown in Figure 1. Furthermore, the vehicle 100 can have additional elements in addition to those shown in Figure 1. In some arrangements, the vehicle 100 can be realized without one or more of the elements shown in Figure 1. Although the elements are shown in Figure 1 as being located within the vehicle 100, it should be clear that one or more of these elements can be located outside the vehicle 100. Furthermore, the elements shown can be physically separated by large distances. For example, as already discussed, one or more components of the disclosed system can be realized within the vehicle 100, while other components of the system can be realized in a cloud environment, as will be discussed further below.

[0021] Some of the possible elements of vehicle 100 are shown in Figure 1 and described in conjunction with the subsequent drawings. However, for the sake of brevity, many of the explanations of the elements in Figure 1 will be presented after the demonstrations in Figures 2-7. In addition, for the sake of simplification and brevity of the illustrations, reference numbers will be repeated in different drawings to show corresponding or similar elements where appropriate. Furthermore, the demonstrations outline many specific details to enable a good understanding of the embodiments described herein. However, those skilled in the art will see that the embodiments described herein can be implemented using various combinations of these elements. In any case, as illustrated in the embodiment of Figure 1, vehicle 100 includes a parking system 170 implemented to carry out methods and other functions as disclosed herein in relation to the selective activation of a parking availability function.

[0022] Furthermore, when installed within vehicle 100, parking system 170 functions in cooperation with communication system 180. In one embodiment, communication system 180 communicates according to one or more communication standards. For example, communication system 180 can include various antennas / transceivers and / or other hardware elements for communicating according to respective protocols at various frequencies. Communication system 180 communicates via a communication protocol such as WiFi, DSRC, V2I, V2V, or other suitable protocol for communicating between vehicle 100 and other entities in a cloud environment in one arrangement. Further, communication system 180, in one arrangement, further communicates according to protocols such as the Global System for Mobile Communications (GSM), Enhanced Data Rate for GSM Evolution (EDGE), Long Term Evolution (LTE), 5G or other communication technologies for vehicle 100 to communicate with various remote devices (e.g., cloud-based servers). In any case, parking system 170 can leverage various wireless communication technologies to communicate with other entities such as members of a cloud computing environment.

[0023] FIG. 2 further illustrates one embodiment of the parking system 170. The parking system 170 includes, in the figure, the processor 110 of the vehicle 100 of FIG. 1. Thus, the processor 110 is part of the parking system 170, or the parking system 170 includes a processor separate from the processor 110 of the vehicle 100, or the parking system 170 can access the processor 110 via a data bus or other communication path. In a further form, the processor 110 is a cloud-based resource. The processor 110 communicates with the parking system 170 through a communication network or can be co-located with the parking system 170. In one embodiment, the parking system 170 includes a memory 210 that stores a control module 220. The memory 210 is a random access memory (RAM), read-only memory (ROM), hard disk drive, flash memory or other suitable memory (volatile or non-volatile) for storing the module 220 and 230 and / or other information used by the parking system 170. The modules 220 and 230 are, for example, computer-readable instructions within the physical memory 210 that cause the processor 110 to perform the various functions disclosed herein when executed by the processor 110.

[0024] As described above, the parking system 170 can further be implemented within the vehicle 100 as part of a cloud-based system that functions within the cloud environment 300, as illustrated in connection with FIG. 3. That is, for example, the parking system 170 can obtain data (e.g., telematics data, sensor data, etc.) from various entities such as distributed vehicles that implement separate instances of the parking system 170. In one or more approaches, the cloud environment 300 can facilitate communication between multiple different vehicles to obtain and distribute information regarding available parking when propagated to various vehicles that are collecting and searching for parking by one or more of the vehicles 310, 320, and 330.

[0025] Therefore, as illustrated, the parking system 170 may include separate instances within one or more entities in the cloud-based environment 300, such as servers, and instances within the vehicle that work collaboratively to acquire, analyze, and distribute the above information. In a further form, the entities that realize the parking system 170 within the cloud-based environment 300 are diverse beyond transportation-related equipment and can include mobile devices (e.g., smartphones) and other devices that individuals can carry in a vehicle and thereby work collaboratively with the vehicle. Thus, the set of entities that work collaboratively with the cloud environment 300 is variable.

[0026] The cloud-based environment 300 itself is a dynamic environment that includes cloud members that move daily into and out of a certain geographic area, as previously described. In general terms, as discussed herein, the geographic area is associated with a broad area such as a city and its surrounding suburbs. As will be discussed in more detail later, the parking system 170 divides the geographic area into regions in at least one sequence and aggregates the information received from vehicles according to the region. In yet another form, the parking system 170 dynamically defines an active region according to the location of a vehicle reporting a long parking search time. In such a case, the parking system 170 defines the active region according to the location of the reporting vehicle. Therefore, the specific size and shape of the active region depend on the location of the reporting vehicle and are not constrained to a predetermined region. In any case, the area associated with the cloud environment 300 can vary depending on the specific implementation and generally spans a wide geographic area.

[0027] Continuing with Figure 2 and the schematic embodiments of the parking system 170, in one or more sequences, the parking system 170 includes a data store 240. In one embodiment, the data store 240 is an electronic data structure (e.g., a database) that is stored in memory 210 or another electronic memory and consists of routines that can be executed by the processor 110 for analyzing the stored data, providing the stored data, organizing the stored data, etc. Thus, in one embodiment, the data store 240 stores data used by modules 220 and 230 when performing various functions. In one embodiment, the data store 240 includes sensor data 250, availability information 260, a parking map 270 and / or other information used by module 220. Although the data store 240 is illustrated as including sensor data 250, availability information 260 and a parking map 270, separate instances of the parking system 170 can realize the data store 240 to include various sets of information.

[0028] In either case, the control module 220 includes instructions that function to control the processor 110 to acquire sensor data 250 and / or availability information 260. Depending on the specific case of the parking system 170 (i.e., in-vehicle versus cloud-based entity), the acquisition of sensor data 250 and / or availability information 260 may differ. For example, in vehicle 100, the control module 220 collects different data elements depending on whether vehicle 100 is in an active area or in another inactive area. Another form of the active area will be discussed later, but it should be seen that the control module 220 refers to the parking map 270 to determine when to activate the parking availability function that causes vehicle 100 to acquire more detailed sensor data 250.

[0029] In the case of a vehicle 100 operating within an inactive area defined by the parking map 270, the control module 220 may acquire availability information 260 that may include trajectory information relating to the movement of the vehicle 100, and in a further form, may include telematics data. Thus, the trajectory information defines the movement of the vehicle 100, such as turns, speed, and braking events, along with the approximate location defined by GPS. Therefore, the trajectory information defines the overall route and the basic characteristics of the route without including resource-intensive information such as camera images and LiDAR point clouds, which are acquired when performing techniques involving machine perception of the surrounding environment. As mentioned above, in a further form, the control module 220 may also acquire telematics data that includes additional forms relating to the operation of the vehicle 100, such as vehicle events (e.g., on / off events, transmission shift events, etc.) and other overall attributes relating to the operation of the vehicle 100.

[0030] Once the control module 220 acquires the availability information 260, it communicates the availability information 260 to the cloud environment 300, where another example of the parking system 170 determines whether the availability information 260 indicates a shortage of parking spaces at a given location. The vehicle 100 can be expected to selectively provide the availability information 260 at set intervals or when a specific event occurs (e.g., a vehicle off-event). Furthermore, the control module 220 within the vehicle 100 can locally process the availability information 260 to derive a search time that is communicated to the cloud rather than the availability information 260 itself.

[0031] Upon moving to the cloud computing environment 300, a control module 220 within the cloud environment 300's equipment, such as a server, receives availability information from the vehicle 100. In at least one approach, the control module 220 then analyzes the availability information 260 to derive the search time spent by the vehicle 100 in searching for a parking space at a given location. In various approaches, the specific manner in which the search time is determined may vary, but it depends on the identification of the start and stop times. The control module 220 can use situational cues to determine when to define the start and stop times. For example, in some cases, the identification of the start time is clear, such as when the availability information 260 includes data elements that indicate when the vehicle 100 entered a parking garage, parking lot, or other area designated for parking. Alternatively, or in addition to this, the control module 220 analyzes the availability information 260 for indicators of when the vehicle 100 is exhibiting a turning pattern indicating a parking search. For example, if vehicle 100 turns around a destination or an area near a destination and then parks, the control module 220 defines a start time as an initial point associated with the turning action. In yet another embodiment, the control module 220 defines a search start time when vehicle 100 is within a set distance of the destination, as determined, for example, according to a navigation command.

[0032] To determine the end time of the search, the control module 220 analyzes the availability information 260 to identify, for example, when vehicle 100 is turned off, when it shifts to parking, or when it indicates behavior in a parking position (i.e., does not move for a set amount of time). In this way, the control module 220 can define the start and end times of the parking search and derive the parking search time spent by vehicle 100 for the parking search. It should also be found that other connected vehicles in the geographic area associated with the cloud computing environment 300 also provide availability information to the parking system 170. Thus, the parking system 170 evaluates separate information from different vehicles (e.g., vehicles 310, 320, and 330) in the same and / or different locations to identify parking trends.

[0033] The parking system 170 uses the derived search time as a comparison point against a time threshold. The time threshold defines the amount of time spent searching for a parking space that indicates a shortage of parking at a given location. The parking system 170 may define different time thresholds for different locations. For example, in areas with complex parking environments, such as large parking garages or parking lots (e.g., at airports), the parking system 170 may define a time threshold that takes into account the time vehicles must travel to and from the parking facilities when the facility is not experiencing a parking shortage. In any case, the control module 220 compares the search time determined from the acquired availability information 260 with the time threshold associated with that location to determine whether the search time meets the threshold (e.g., is greater than or equal to the threshold). If it does not, the control module 220 discards or otherwise records the search time.

[0034] However, if the search time meets a threshold, the control module 220 records the search time as a parking event for that location and aggregates the search time together with other parking events for that location. In this way, the control module 220 can identify the occurrence of vehicles having difficulty parking and track additional instances to infer when it is difficult to find parking in a given location. Furthermore, by using trajectory information / telematic data instead of relying on active perception within the vehicle, the parking system facilitates resource conservation within the connected vehicle.

[0035] Continuing the discussion of the operation of the control module 220 within the cloud-based entity, once the control module 220 has totaled the search time, it periodically updates the parking map 270. The parking map 270 is a map of the geographical area where the parking system 170 actively monitors parking availability. The parking map 270 includes demarcated areas (e.g., grid cells), or simply the locations of parking events demarcated from search times that meet a time threshold, as will be discussed in more detail later. Thus, when the search time for a particular location meets the parking threshold, the control module 220 updates the parking map 270 to reflect the search time and the active area associated with it.

[0036] To further explain the parking threshold, the control module 220 defines the parking threshold in at least one array according to the sliding time frame (e.g., the preceding 60 minutes) and the number of parking events occurring within the sliding frame. In a further embodiment, the control module 220 can average the search time within the sliding frame to determine when the average time to park satisfies the parking threshold. Thus, when multiple vehicles report search times indicating difficulty in parking within the sliding frame, the control module 220 switches the relevant area in the parking map 270 to an active area. The control module 220 further provides (communicates) the parking map 270 to connected vehicles, which use the parking map 270 to know where the parking availability function should be active.

[0037] Therefore, as the vehicle 100 drives through a geographical area, the control module 220 within the vehicle 100 compares its current location with the parking map 270 to determine when the vehicle 100 enters an active area. In the active area, the control module 220 activates the parking availability function in the vehicle 100. In various embodiments, the parking availability function schematically includes actively identifying available parking spaces by using the vehicle's onboard sensors to acquire sensor data about the surrounding environment and analyzing the sensor data using various machine perception techniques. Thus, as a vehicle with this functionality drives through an area where parking is limited, the vehicle uses perceived information about its surroundings to identify the location of available parking spaces.

[0038] The parking availability function can be implemented as part of the autonomous driving module 160 or as part of the parking system 170. As one embodiment, implementation via the parking system 170 will be briefly described. In one configuration, the control module 220 acquires sensor data 250 in the environment surrounding the vehicle 100 to facilitate the operation of various systems of the vehicle 100, such as the autonomous driving module 160 (e.g., an automated driver assistance system (ADAS), a semi-autonomous system, a fully autonomous system, etc.), a navigation application, and the parking availability function. In a further instance, the control module 220 acquires sensor data 250 related to the operation of the vehicle 100 itself (e.g., trajectory data, system status information, diagnostic data, etc.) and other relevant operating features that report the determination of parking availability.

[0039] Therefore, the control module 220 generally includes instructions that cause the processor 110 to control one or more sensors of the vehicle 100 to generate observations about the surrounding environment. In a broad sense, observations, when acquired by the control module 220, are information about a specific driving environment (e.g., a parking lot, a road, etc.) and objects present in the driving environment as perceived by at least one sensor. Thus, observations are generally a group of one or more data points that are processed into a meaningful form.

[0040] In one embodiment, the control module 220 controls each sensor of the vehicle 100 to provide data input in the form of sensor data 250. The control module 220 can further process the sensor data 250 into distinct observations of the surrounding environment. For example, in one approach, the control module 220 can merge data from distinct sensors to provide observations about a particular form of the surrounding environment. For example, the sensor data 250 itself may take the form of distinct images, laser returns, LiDAR returns, etc., in one or more approaches. The control module 220 can derive decision values ​​(e.g., location, trajectory, etc.) from the sensor data 250 and merge the data about distinctly identified forms of the surrounding environment, such as surrounding vehicles. The control module 220 can further extrapolate the sensor data 250 into a single observation by correlating distinct instances of sensor data with meaningful observations about objects beyond instantaneous data points, for example. For example, the control module 220 can track surrounding vehicles across many data points to provide a track or to determine whether surrounding vehicles are about to leave the parking space.

[0041] Furthermore, while the control module 220 is discussed as controlling various sensors to provide sensor data 250, in one or more embodiments, the module 220 may employ other active or passive techniques to acquire the sensor data 250. For example, the control module 220 may passively sniff out the sensor data 250 from the stream of electronic information that various sensors or other modules / systems in the vehicle 100 provide to other components in the vehicle 100. Moreover, as mentioned above, the control module 220 may take various approaches to fusing data from multiple sensors when providing sensor data 250. Thus, in one embodiment, the sensor data 250 represents a combination of perceptions acquired from multiple sensors.

[0042] Naturally, the available sensor data 250 that the parking system 170 can collect may vary depending on the sensors included in the vehicle 100 or other entity. As one example, depending on the particular implementation, the vehicle 100 may include various types of cameras or arrangements of multiple cameras. When acquiring sensor data 250, the control module 220 may acquire various electronic inputs emitted by the vehicle 100, which can be stored as sensor data 250 in the data store 240 of the parking system 170 and processed according to various algorithms such as machine learning algorithms and heuristics. Thus, the parking system 170 uses the above sensor data 250, along with perceptions derived from the sensor data 250, in one approach to identify available parking locations along the road and within parking facilities.

[0043] The parking system 170 can then communicate the observations derived for propagation to the cloud-based environment 300 and return them to the vehicle currently searching for parking. The cloud-based environment 300 can also issue commands to various connected vehicles to improve their knowledge of available parking spaces, such as rerouting vehicles to observe specific areas (e.g., where available space has been previously observed). The resources consumed by connected vehicles to support this function are considerable. Therefore, using the parking availability function in areas where parking is not inconvenient generally results in a waste of resources employed by vehicles supporting this function. This is especially true in cases where the vehicle is an electric vehicle with limited energy.

[0044] An additional form of selective activation of the parking availability function according to the active area will be explained with reference to Figure 4. Figure 4 is a flowchart of Method 400 related to updating the parking map by identifying the active area where parking is limited. Method 400 is discussed from the perspective of the parking system 170 in Figures 1-2 when implemented by entities such as servers in a cloud-based environment 300. Although Method 400 is discussed in combination with the parking system 170, it should be seen that Method 400 is not limited to being implemented within the parking system 170, but is an example of a system in which Method 400 can be implemented. Furthermore, although the method is generally shown as a serial process, various forms of Method 400 can be executed in parallel to perform the above functions.

[0045] In 410, the control module 220 receives availability information 260, which includes trajectory information relating to the movement of the search vehicle. The trajectory information includes at least a start time and a stop time associated with the search vehicle searching for a parking spot. In particular, the trajectory information includes information from which the control module 220 can derive the start time and stop time. Furthermore, as previously stated, the availability information 260 may also include a set of telematics data specifying additional forms relating to the operation of the vehicle 100, such as vehicle on / off events, thereby facilitating the determination of the start time and stop time.

[0046] In 420, the control module 220 estimates the search time spent by the vehicle 100 searching for parking at a given location. In at least one approach, the control module 220 estimates the search time by identifying the start time as when the searching vehicle 100 begins searching for a parking spot and the stop time as when the vehicle comes to a stop. The start time and stop time can be identified according to a variety of criteria, including identifying when the vehicle 100 begins a start and stop pattern that indicates frequent operations in the parking facility to identify a parking space, identifying when the vehicle 100 turns around in the same geographic area, identifying when the distance to the destination meets a threshold (e.g., a predetermined distance within which the vehicle 100 begins searching for parking), and when the vehicle 100 enters the parking area. Similarly, the control module 220 determines the stop time for parking according to availability information 260, such as a vehicle off event and a transmission shift event to parking. From these indicators, the control module 220 derives the search time.

[0047] In 430, the control module 220 determines whether the search time meets a time threshold. The time threshold indicates when the location reaches a level of parking availability that prolongs the vehicle 100's discovery of available parking. For example, with respect to a parking garage, the time to find parking increases considerably when the parking garage is full and only spots for vehicles leaving are available. Similarly, the time to find parking also increases if the vehicle has to travel through many floors of the parking garage (e.g., to the top floor). Thus, the parking system 170 can define a time threshold to account for the extension of parking time, and further, it can define a time threshold depending on the specific location, which may include additional travel time associated with entering the parking facility.

[0048] In 440, the control module 220 aggregates the observation and search times associated with additional entities parking at locations previously identified as meeting a time threshold. The aggregated search time provides a more comprehensive assessment of how many vehicles are parked at that location and in various parking facilities such as diverse parking garages, parking lots, and street parking. Furthermore, it should be found that the observation time can be assessed within predetermined sliding timeframes (e.g., 30 minutes, 60 minutes, etc.) to see changes in parking at a given location in real time.

[0049] In 450, the control module 220 determines whether a given location meets a parking threshold indicating a shortage of available parking spaces at that location. As previously described, the parking threshold can be defined as the number of vehicle search times that meet a time threshold or the average reported search time that meets the parking threshold. Both indicators represent an increase in parking activity at a given location. Furthermore, while we will discuss locations in a broad sense, it should be understood that locations generally refer to the same area within the parking map 270, as will be discussed further with Figures 6-7. In any case, the control module 220, in one configuration, analyzes observed times along with historical data about parking at a given location to determine whether the location meets the parking threshold. Therefore, the analysis can include additional inferences if the parking threshold is not met by observed times alone, in combination with historical data. For example, historical data may include overall parking demand according to previously observed demand, event occurrences, etc., within the location. Therefore, the control module 220 can be adjusted by a historical prediction coefficient (for example, by increasing the observation time according to the predicted future demand) to better predict parking demand at that location. Thus, when the total search time meets the parking threshold, the control module 220 updates the parking map at 460. Otherwise, the parking system 170 continues to monitor the search time.

[0050] In 460, the control module 220 updates the parking map 270 according to the observed time. The parking map 270 identifies active areas where parking is currently unavailable in order to inform connected vehicles about areas where the parking availability function should be activated. The identification of active areas may vary depending on the specific implementation, as previously described. For example, a geographical area may be divided into separate grid cells using a grid. When a particular cell associated with a search time meets the parking threshold, the control module 220 changes the notation in the parking map 270 to indicate that cell as an active area. In further forms, the delimitation of active areas may be vague in the sense that the control module 220 identifies a particular location associated with a search time and forms an area with respect to time in order to cluster occurrences together.

[0051] In 470, the control module 220 provides a parking map 270 containing the active area to identified vehicles located near a location associated with the active area. In one or more arrays, the control module provides the parking map 270 by periodically communicating the parking map 270 to vehicles in a geographic area associated with the active area. In yet another approach, the control module 220 can provide the parking map 270 whenever an area is updated to an active state or deactivated to an inactive state (i.e., when the observation time no longer meets the parking threshold and / or depending on the cool-down period). In any case, by communicating the parking map 270 to the vehicle, the vehicle is made to actively sense the available parking space in the active area and communicate the available space back to the cloud-based environment 300, facilitating parking by following vehicles.

[0052] The vehicle can then leverage the parking map 270 to determine when the parking availability function should be activated, thereby saving resources by disabling the parking identification function in inactive zones. As described above, the information obtained regarding available parking can be propagated separately or as part of the parking map 270 to vehicles in the active area to inform vehicles searching for parking which spaces are likely to be available.

[0053] Figure 5 is a flowchart of Method 500 associated with the selective activation of the parking availability function in a connected vehicle. Method 500 is discussed from the perspective of the parking system 170 shown in Figures 1-2, which is implemented by a vehicle such as vehicle 100. Although Method 500 is discussed in combination with the parking system 170, Method 500 is not limited to being implemented within the parking system 170, but is an example of a system in which Method 500 can be implemented. Furthermore, although the method is illustrated as a generally serial process, various forms of Method 500 can be executed in parallel to perform a specified function.

[0054] In 510, the parking system 170 determines whether the vehicle 100 is currently within an active area defined by the parking map 270. In one or more sequences, the control module 220 determines the location of the vehicle 100 by referring to information from GPS or other location identification sensors and compares this location with the parking map 270. The comparison identifies the vehicle's current area and whether the current area is active in comparison with the parking map 270. If the vehicle 100 is not within an active zone, the control module 220 proceeds to communicate availability information 260 as discussed in 550. Otherwise, the control module activates the parking availability function as further discussed in 520-540.

[0055] In step 520, the control module 220 acquires sensor data 250 about the surroundings of the vehicle 100. The sensor data 250 represents ambient observations, including information about available parking spaces. As previously mentioned, the sensor data 250 may include information from a set of sensors that facilitate the capture of comprehensive observations of the surrounding environment.

[0056] In 530, the control module 220 analyzes the sensor data 250 to identify parking availability. In various sequences, the control module 220 processes the sensor data 250 using various algorithms to detect objects and shapes in the environment, classify objects, and determine the presence of parked vehicles and free space for parking in the surrounding environment. In practice, the process of identifying available parking may include the analysis of various situational forms such as the size of the space and the presence of signs indicating parking rules / laws. In any case, through the analysis of the sensor data 250, the control module 220 can identify available parking locations.

[0057] In 540, the control module 220 communicates the location of available parking spaces to the cloud-based environment 300. In various arrays, the control module 220 communicates via a cellular communication link to provide observational information, which can then be provided to other vehicles to facilitate parking.

[0058] In 550, the control module 220 communicates availability information 260 to the cloud-based environment 300. As previously described, the availability information 260 includes at least trajectory information relating to the vehicle 100's path so that the entity in the cloud-based environment 300 can determine whether the vehicle 100 will encounter parking difficulties as derived from the availability information. Thus, the vehicle 100 provides different sets of information depending on whether the vehicle 100 is currently operating within the active area. In this way, the vehicle 100 can conserve resources and avoid additional processing and communication when operating outside the active area.

[0059] For further explanation of the parking system 170, see Figures 6-7. Figure 6 shows an example of a geographic area 600 divided according to a grid. X identifies the location where a vehicle reported a search time that the parking system 170 determines meets a time threshold. Furthermore, grid cells 610, 620, and 630 are active areas because the parking system 170 has determined that the observed time contained within them meets the parking threshold. Therefore, connected vehicles traveling within the active areas 610, 620, and 630 are guided to activate the parking availability function so that the parking system 170 can assist other vehicles in finding parking.

[0060] Figure 7 shows another example of geographical area 700, differing in that area 700 is not divided into grid cells. Instead, the parking system 170 clusters the observed times. For example, the parking system can dynamically generate vague active areas rather than using predefined sub-regions to better capture areas where parking is difficult. As illustrated, the parking system 170 applies a clustering algorithm to the locations where parking delay events are identified from the reported search times. Following the clustering, the parking system 170 defines the active areas to include as many parking events as reasonable without unnecessarily defining boundaries for inactive areas. Thus, as shown in Figure 7, the parking system 170 defines an active area 710 that encompasses parking events that are generally close to each other without extending the active area 710 too far and capturing parking events that are far removed from the primary group.

[0061] Next, with respect to Figure 1, we will discuss in detail examples of environments in which the systems and methods disclosed herein can operate. In some cases, the vehicle 100 is configured to selectively switch between autonomous mode, one or more semi-autonomous operating modes and / or manual mode. Naturally, in further forms, the vehicle 100 may be a manual driving vehicle with or without one or more driver assistance systems such as an inter-vehicle distance control system, lane keeping assist, and crash avoidance. In any case, “manual mode” means that all or most of the vehicle’s navigation and / or operation is performed according to input received from a user (e.g., a human driver). In one or more sequences, the vehicle 100 may be a conventional vehicle configured to operate only in manual mode.

[0062] In one or more embodiments, the vehicle 100 is an autonomous vehicle. As used herein, “autonomous vehicle” means a vehicle operating in autonomous mode. “Autonomous mode” means navigating and / or operating the vehicle 100 along a route using one or more computing systems to control the vehicle 100 with minimal or no input from a human driver. In one or more embodiments, the vehicle 100 is highly automated or fully automated. In one embodiment, the vehicle 100 is configured to have one or more semi-autonomous operating modes in which one or more computing systems perform a portion of the vehicle’s navigation and / or operation along a route, and a vehicle operator (i.e., driver) provides input to the vehicle to perform a portion of the vehicle’s navigation and / or operation along a route.

[0063] Vehicle 100 may include one or more processors 110. In one or more arrays, one or more processors 110 may be the main processor of vehicle 100. For example, one or more processors 110 may be an electronic control unit (ECU). Vehicle 100 may include one or more data stores 115 for storing one or more types of data. The data stores 115 may include volatile and / or non-volatile memory. Examples of suitable data stores 115 include RAM (random access memory), flash memory, ROM (read-only memory), PROM (programmable read-only memory), EPROM (erasable programmable read-only memory), EEPROM (electronically erasable programmable read-only memory), registers, magnetic disks, optical disks, hard drives, or any other suitable storage medium or any combination thereof. The datastore 115 is a component of one or more processors 110, or the datastore 115 can be operationally connected to the processor 110 for use by one or more processors. “Operationally connected” as used in this description may include direct or indirect connections, including connections without direct physical contact.

[0064] In one or more arrays, one or more data stores 115 may include map data 116. Map data 116 may include maps consisting of one or more geographic areas. In some cases, map data 116 may include information or data about roads, traffic control equipment, road markings, structures, features and / or landmarks in one or more geographic areas. Map data 116 can be in any appropriate format. In some cases, map data 116 may include aerial photographs of the area. In some cases, map data 116 may include ground photographs of a given area, including 360-degree ground photographs. Map data 116 may include measurements, dimensions, distances and / or information about one or more items included in map data 116 and / or information about other items included in map data 116. Map data 116 may include digital maps with information about road shapes. Map data 116 may be of high quality and / or very detailed.

[0065] In one or more arrays, map data 116 may include one or more topographic maps 117. A topographic map(s) 117 may include information about the ground, terrain, roads, surface and / or other features of one or more geographic areas. A topographic map(s) 117 may include elevation data for one or more geographic areas. Map data 116 may be of high quality and / or very detailed. A topographic map(s) 117 may define one or more surfaces, which may include paved roads, unpaved roads, land and other surfaces that define the surface.

[0066] In one or more arrays, map data 116 may include one or more stationary obstacle maps 118. A stationary obstacle map (one or more) 118 may include information about one or more stationary obstacles located within one or more geographical areas. A “stationary obstacle” is a physical object whose location does not change or substantially change over a period of time and / or whose size does not change or substantially change over a period of time. Examples of stationary obstacles include trees, buildings, curbs, fences, railings, center lines, utility poles, statues, monuments, signs, benches, fixtures, mailboxes, large rocks, and hills. A stationary obstacle can be an object extending from the ground. One or more stationary obstacles included in a stationary obstacle map (one or more) 118 may have location data, size data, dimension data, material data, and / or other data associated therewith. A stationary obstacle map (one or more) 118 may include measurements, dimensions, distances, and / or information about one or more stationary obstacles. The stationary obstacle map(s)118 can be of high quality and / or very detailed. The stationary obstacle map(s)118 can be updated to reflect changes within the area being mapped.

[0067] One or more data stores 115 may contain sensor data 119. In this context, “sensor data” means any information relating to the sensors equipped on the vehicle 100, including the function of the sensors and other information relating to the sensors. As described below, the vehicle 100 may include a sensor system 120. The sensor data 119 may relate to one or more sensors of the sensor system 120. As one example, in one or more arrays, the sensor data 119 may include information relating to one or more LIDAR sensors 124 of the sensor system 120.

[0068] In some cases, at least a portion of the map data 116 and / or sensor data 119 may be located in one or more data stores 115 mounted on the vehicle 100. Alternatively, or in addition to this, at least a portion of the map data 116 and / or sensor data 119 may be located in one or more data stores 115 located away from the vehicle 100.

[0069] As described above, the vehicle 100 may include a sensor system 120. The sensor system 120 may include one or more sensors. "Sensor" means any device, component and / or system that can detect and / or sense something. One or more sensors may be configured to detect and / or sense in real time. As used herein, "real time" means a level of processing responsiveness that is sufficiently immediate for a user or system to sense or for a processor to keep up with some external process for a particular process or decision to be made.

[0070] In the sensor system 120, in an array containing multiple sensors, the sensors can operate independently of each other, or two or more sensors can operate coupled together. In such cases, two or more sensors can form a sensor network. The sensor system 120 and / or one or more sensors can be operationally connected to one or more processors 110, one or more data stores 115, and / or other elements of the vehicle 100 (including any of the elements shown in Figure 1). The sensor system 120 can acquire data from at least a portion of the external environment of the vehicle 100 (e.g., nearby vehicles).

[0071] The sensor system 120 may include various types of sensors. Various examples of these sensors are discussed below in this specification. However, it should be noted that the embodiments are not limited to the specific sensors described. The sensor system 120 may include one or more vehicle sensors 121. One or more vehicle sensors 121 can detect, determine, and / or sense information about the vehicle 100 itself. In one or more arrays, the vehicle sensors 121 may be configured to detect and / or sense changes in the position and orientation of the vehicle 100, for example, based on inertial acceleration. In one or more arrays, the vehicle sensors 121 may include one or more accelerometers, one or more gyroscopes, inertial measurement units (IMUs), dead reckoning systems, global navigation systems (GNSS), global positioning systems (GPS), navigation systems 147, and / or other suitable sensors. The vehicle sensor(s) 121 can be configured to detect and / or sense one or more features of the vehicle 100. In one or more arrays, the vehicle sensor(s) 121 may include a speedometer for determining the current speed of the vehicle 100.

[0072] Alternatively, or in addition to the above, the sensor system 120 may include one or more environmental sensors 122 configured to acquire and / or sense driving environment data. "Driving environment data" includes data or information relating to the external environment in which the autonomous vehicle is located or to one or more parts thereof. For example, one or more environmental sensors 122 may be configured to detect, quantify and / or sense obstacles and / or information / data relating to such obstacles in at least one part of the external environment of the vehicle 100. Such obstacles may be stationary and / or moving objects. One or more environmental sensors 122 may be configured to detect, measure, quantify and / or sense other things in the external environment of the vehicle 100, such as lane markers, signs, traffic signals, lanes, intersections, curbs adjacent to the vehicle 100, and off-road objects.

[0073] Various examples of sensors in the sensor system 120 are described herein. Sensor examples may be part of one or more environmental sensors 122 and / or one or more vehicle sensors 121. However, it should be noted that the embodiments are not limited to the specific sensors described.

[0074] For example, in one or more arrays, the sensor system 120 may include one or more radar sensors 123, one or more LiDAR sensors 124, one or more sonar sensors 125, and / or one or more cameras 126. In one or more arrays, one or more cameras 126 may be high dynamic range (HDR) cameras or infrared (IR) cameras.

[0075] Vehicle 100 may include an input system 130. The "input system" includes any device, component, system, element, or array or group thereof that enables information / data to be input into the machine. The input system 130 may receive input from vehicle passengers (e.g., the driver or passengers). Vehicle 100 may include an output system 135. The "output system" includes any device, component, or array or group thereof that enables information / data to be presented to vehicle passengers (e.g., people, vehicle passengers, etc.).

[0076] Vehicle 100 may include one or more vehicle systems 140. Various examples of one or more vehicle systems 140 are shown in Figure 1. However, vehicle 100 may include more, fewer, or different vehicle systems. Although specific vehicle systems are illustrated separately, each or any of the systems or parts thereof can be coupled or separated within vehicle 100 via hardware and / or software. Vehicle 100 may include a propulsion system 141, a braking system 142, a steering system 143, a throttle system 144, a transmission system 145, a signaling system 146, and / or a navigation system 147. Each of these systems may include one or more devices, components, and / or combinations thereof that are currently known or will be developed in the future.

[0077] The navigation system 147 may include one or more currently known or hereafter developed devices, applications, and / or combinations thereof configured to determine the geographical location of the vehicle 100 and / or the route of the vehicle 100. The navigation system 147 may include one or more mapping applications for determining the route of the vehicle 100. The navigation system 147 may include a global positioning system, a local positioning system, or a geolocation system.

[0078] The processor(s) 110, parking system 170, and / or autonomous driving module(s) 160(s) can be operationally connected to communicate with various vehicle systems 140 and / or their individual components. For example, as shown in Figure 1, the processor(s) 110 and / or autonomous driving module(s) 160 can communicate with and / or receive information from various vehicle systems 140 to control the movement, speed, operation, direction, and orientation of the vehicle 100. The processor(s) 110 and / or autonomous driving module(s) 160 can control some or all of these vehicle systems 140 and can therefore be partially or fully autonomous.

[0079] The processor(s) 110 and / or the autonomous driving module(s) 160 can be operationally connected to communicate with various vehicle systems 140 and / or their individual components. For example, as shown in Figure 1, the processor(s) 110, the parking system 170 and / or the autonomous driving module(s) 160 can communicate to and / or receive information from the various vehicle systems 140 to control the movement, speed, operation, direction, and orientation of the vehicle 100. The processor(s) 110, the parking system 170 and / or the autonomous driving module(s) 160 can control some or all of these vehicle systems 140.

[0080] The processor(s) 110 and / or the autonomous driving module(s) 160 can be activated to control the navigation and / or operation of the vehicle 100 by controlling the vehicle system 140 and / or one or more of its components. For example, when operating in autonomous mode, the processor(s) 110 and / or the autonomous driving module(s) 160 can control the direction and / or speed of the vehicle 100. The processor(s) 110 and / or the autonomous driving module(s) 160 can cause the vehicle 100 to accelerate (e.g., by increasing fuel supply to the engine), decelerate (e.g., by decreasing fuel supply to the engine and / or by applying the brakes), and / or change direction (e.g., by turning the two front wheels). As used herein, "to cause" means to cause, compel, instruct, command, order and / or enable an event or action to occur or to be in a state in which such an event or action occurs, directly or indirectly.

[0081] The vehicle 100 may include one or more actuators 150. The actuators 150 can be any element or combination of elements that can be actuated to modify, adjust and / or change one or more of the vehicle system 140 or its components in response to receiving signals or other inputs from one or more processors 110 and / or one or more autonomous driving modules 160. Any suitable actuator can be used. For example, one or more actuators 150 may include, for example, motors, pneumatic actuators, hydraulic pistons, relays, solenoids and / or piezoelectric actuators.

[0082] Vehicle 100 may include one or more modules, at least some of which are described herein. A module can be implemented as computer-readable program code that, when executed by processor 110, implements one or more of the various processes described herein. One or more modules may be components of processor(s) 110, or one or more modules may run on and / or be distributed among other processing systems to which processor(s) 110 is operationally connected. A module may include instructions (e.g., program logic) that can be executed by one or more processor(s) 110. Alternatively or in addition to this, one or more data stores 115 may include such instructions.

[0083] In one or more arrays, one or more of the modules described herein may include artificial intelligence or computational intelligence elements, such as neural networks, fuzzy logic, or other machine learning algorithms. Furthermore, in one or more arrays, one or more modules may be distributed among the modules described herein. In one or more arrays, two or more of the modules described herein may be combined into a single module.

[0084] Vehicle 100 may include one or more autonomous driving modules 160. Each autonomous driving module 160 can be configured to receive data from the sensor system 120 and / or any other type of system capable of capturing information about the vehicle 100 and / or the external environment surrounding the vehicle 100. In one or more arrays, each autonomous driving module 160 can use such data to generate one or more driving scene models. Each autonomous driving module 160 can determine the position and speed of the vehicle 100. Each autonomous driving module 160 can determine other environmental features, including the location of obstacles, obstacles or traffic signals, trees, shrubs, nearby vehicles, and pedestrians.

[0085] The autonomous driving module(s) 160 may be configured to receive and / or determine location information regarding obstacles in the external environment of the vehicle 100 for use by the processor(s) 110 and / or one or more of the modules described herein, in order to estimate the position and orientation of the vehicle 100 and the position of the vehicle in global coordinates, based on signals from multiple satellites or any other data and / or signals that can be used to determine the position of the vehicle 100 in its environment for use in determining the current state of the vehicle 100 or when generating a map or determining the position of the vehicle 100 relative to map data.

[0086] The autonomous driving module(s) 160 may be configured, independently or in combination with the parking system 170, to determine a driving path(s), current autonomous driving operations of the vehicle 100, future autonomous driving operations, and / or modifications to the current autonomous driving operations, based on data from any other suitable source, such as data acquired by the sensor system 120, a driving scene model, and / or determinations from the sensor data. “Driving operations” means one or more actions that affect the movement of the vehicle. Examples of driving operations include, for example, acceleration, deceleration, braking, turning, moving the vehicle 100 laterally, changing driving lanes, merging into traffic, and / or reversing. The autonomous driving module(s) 160 may be configured to implement the determined driving operations. The autonomous driving module(s) 160 may be configured to directly or indirectly cause such autonomous driving operations to occur. As used herein, “to cause” means to cause, command, instruct, order, and / or enable an event or action to occur or to be in a state in which such an event or action occurs, directly or indirectly. The autonomous driving module(s) 160 can be configured to perform various vehicle functions and / or send data to and receive data from the vehicle 100 or one or more of its systems (e.g., one or more of the vehicle systems 140), interact with it, and / or control it.

[0087] Detailed embodiments are disclosed herein. However, it should be understood that the disclosed embodiments are merely examples. Accordingly, the specific structural and functional details disclosed herein should not be construed as restrictive, but merely as criteria for the claims and as representative criteria to teach those skilled in the art how to employ the forms herein in various ways in virtually any suitable detailed structure. Furthermore, the terms and phrases used herein are not intended to be restrictive, but are intended to provide explanations for understanding possible implementations. Various embodiments are shown in Figures 1 to 7, but embodiments are not limited to the illustrated structures or applications.

[0088] The flowcharts and block diagrams illustrated illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments. In this regard, each block in a flowchart or block diagram may represent a module, segment, or code portion containing one or more executable instructions for implementing a specified logical function(s). In some alternative implementations, it will be found that the functions shown in a block may not be in the order shown in the diagram. For example, two consecutively shown blocks may actually be executed substantially simultaneously, or blocks may sometimes be executed in reverse order depending on the associated functionality.

[0089] The systems, components, and / or processes described above can be implemented in hardware or in a combination of hardware and software, and can be implemented centrally in a single processing system or in a distributed manner where various elements are distributed across several interconnected processing systems. Any type of processing system or other device is suitable for performing the methods described herein. A typical combination of hardware and software is a processing system having computer-readable program code that, when loaded and executed, controls the processing system to perform the methods described herein. The systems, components, and / or processes can also be embedded in computer-readable storage devices, such as computer program products, or other machine-readable data program storage devices, which tangibly embody a program of machine-executable instructions for performing the methods and processes described herein. These elements can also be embedded in application products that include all the features enabling the implementation of the methods described herein and, when loaded into a processing system, can perform these methods.

[0090] Furthermore, the arrangements described herein may take the form of a computer program product embodied in one or more computer-readable media, for example, stored on which one or more computer-readable program codes are embodied. Any combination of one or more computer-readable media may be used. The computer-readable media may be a computer-readable signal medium or a computer-readable storage medium. "Computer-readable storage medium" means a non-temporary storage medium. The computer-readable storage medium may be, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or equipment or any suitable combination thereof. More specific examples of computer-readable storage devices (non-exclusive list) include portable computer diskettes, hard disk drives (HDDs), solid-state drives (SSDs), read-only memory (ROM), erasable programmable read-only memory (EPRON or flash memory), portable compact disc read-only memory (CD-ROM), digital multi-purpose discs (DVDs), optical storage devices, magnetic storage devices or any suitable combination thereof. In the context of this document, a computer-readable storage medium can be any tangible medium that contains or can store a program for use by or in connection with an instruction execution system, device, or apparatus.

[0091] In general terms, as used herein, a module includes routines, programs, objects, components, data structures, etc., that perform a particular task or realize a particular data type. In further forms, memory generally stores the above-mentioned module. The memory associated with a module may be a buffer or cache embedded in a processor, RAM, ROM, flash memory, or another suitable electronic storage medium. In yet another form, the module envisioned in this disclosure may be implemented as an application-specific integrated circuit (ASIC), a hardware component of a system on a chip (SoC), as a programmable logic array (PLA), or as another suitable hardware component into which a defined set of configurations (e.g., instructions) for performing the disclosed functions is embedded.

[0092] Program code embodied on a computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wireline, optical fiber, cable, RF, and any suitable combination thereof. Computer program code for performing operations for this array can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java®, Smalltalk, C++, or similar, and traditional procedural programming languages ​​such as the "C" programming language or similar. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can connect to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or to an external computer (for example, via the Internet using an Internet service provider).

[0093] The singular article, as used herein, means one or more. "Plural," as used herein, means two or more. "Another," as used herein, means at least a second or more. "Includes" and / or "having," as used herein, means encompassing (i.e., open language). "At least one of," as used herein, means any possible combination of one or more of the listed items in question, including them. For example, "at least one of A, B, and C" includes A only, B only, C only, or any combination thereof (e.g., AB, AC, BC, or ABC).

[0094] The forms described herein can be embodied in other forms without departing from their essence or fundamental attributes. Therefore, the following claims, rather than the above specification, should be used to indicate the scope of this disclosure.

Claims

1. 1. A parking system for improving identification of available parking spaces in a congestion zone, comprising: one or more processors; A memory, communicatively coupled to the one or more processors; When executed by the one or more processors, the one or more processors estimating a search time spent by the search vehicle searching for parking at a predetermined location in response to receiving trajectory information regarding the movement of the search vehicle; aggregate the search time with an observation time associated with an additional entity parking at the location when the search time meets a time threshold; updating a parking map according to the observation time when the observation time meets a parking threshold indicating a shortage of available parking at the location, the parking map identifying an active area where parking is currently lacking; providing the parking map including the active area to an identified vehicle proximate a location associated with the active area; a memory for storing a control module including instructions; A parking system comprising:

2. 10. The parking system of claim 1, wherein the control module includes instructions for receiving trajectory information including instructions for receiving at least a start time and a stop time associated with the search vehicle searching for a parking spot in one of a parking lot, a parking garage, and on-street parking.

3. 3. The parking system of claim 2, wherein the control module includes instructions for estimating the search time, including instructions for identifying the start time as when the search vehicle begins searching for the parking spot and the stop time as when the search vehicle parks, including identifying the start time as at least one of: identifying when the search vehicle begins a start and stop pattern; identifying when the search vehicle circles the same geographic area; identifying a distance to a destination meeting a threshold; and identifying when the search vehicle enters a parking area.

4. 10. The parking system of claim 1, wherein the control module includes instructions for aggregating an observation time and the search time, including instructions for determining whether the search time meets a time threshold that indicates when the location has reached a level of parking availability that postpones finding available parking.

5. the control module includes instructions for defining sub-regions for an entire geographic area including the locations associated with each one of the sub-regions, and for updating the parking map to apply a sliding time window to the observation times for the sub-regions to determine when the average time to park in a sliding window meets the parking threshold; the control module includes instructions for updating the parking map, including instructions for identifying the active area as each one of the sub-areas that meets the parking threshold. The parking system according to claim 1 .

6. the control module includes instructions for providing the parking map, including instructions for communicating the parking map to the identified vehicle to cause the identified vehicle to actively sense available parking spaces in the active area and communicate the available spaces to facilitate parking by a following vehicle; the control module includes instructions for providing the parking map including the active area, for causing each one of the identified vehicles within the active area to activate a parking identification function, and for causing each one of the identified vehicles not within the active area to conserve resources by disabling the parking identification function. The parking system according to claim 1 .

7. 2. The parking system of claim 1, wherein the control module includes instructions for providing the parking map, including instructions for communicating space information identifying locations of available parking spaces at the location according to information obtained from the location.

8. 6. The parking system of claim 5, wherein the control module includes instructions for updating the parking map, including instructions for analyzing the observed time in combination with historical data regarding parking in the sub-regions to determine whether each one of the sub-regions meets the parking threshold.

9. 1. A non-transitory computer-readable medium storing instructions for improving identification of available parking spaces in a congestion zone, the instructions comprising: When executed by one or more processors, the one or more processors: estimating a search time spent by the search vehicle searching for parking at a predetermined location in response to receiving trajectory information regarding the movement of the search vehicle; aggregate the search time with an observation time associated with an additional entity parking at the location when the search time meets a time threshold; updating a parking map according to the observation time when the observation time meets a parking threshold indicating a shortage of available parking at the location, the parking map identifying active areas where parking is currently scarce; providing the parking map including the active area to an identified vehicle proximate a location associated with the active area; Non-transitory computer-readable medium.

10. 10. The non-transitory computer-readable medium of claim 9, wherein the instructions include instructions for receiving the trajectory information, including instructions for receiving at least a start time and a stop time associated with the search vehicle searching for a parking spot in one of a parking lot, a parking garage, and on-street parking.

11. 11. The non-transitory computer-readable medium of claim 10, wherein the instructions include instructions for estimating the search time, including instructions for identifying when the search vehicle begins searching for the parking spot as the start time and when the search vehicle parks, including identifying the start time as at least one of: identifying when the search vehicle begins a start and stop pattern; identifying when the search vehicle circles the same geographic area; identifying when a distance to a destination meets a threshold; and when the search vehicle enters a parking area.

12. 10. The non-transitory computer-readable medium of claim 9, wherein the instructions include instructions for aggregating an observation time and the search time, including instructions for determining whether the search time meets a time threshold indicating when the location has reached a level of parking availability that postpones finding available parking.

13. the instructions include instructions for updating the parking map, including instructions for defining sub-regions in a geographic area that include the locations associated with each one of the sub-regions, applying the sliding time window to the observation times for the sub-regions to determine when an average time for parking over the sliding time window meets the parking threshold; the instructions include instructions for updating the parking map, including instructions for identifying the active area as each one of the sub-areas that meets the parking threshold. The non-transitory computer-readable medium of claim 9.

14. estimating a search time spent by the vehicle searching for parking at a predetermined location in response to receiving trajectory information regarding the movement of the search vehicle; aggregate the search time with an observation time associated with an additional entity parking at the location when the search time meets a time threshold; updating a parking map according to the observation time when the observation time meets a parking threshold indicating a shortage of available parking at the location, the parking map identifying active areas where parking is currently lacking; providing the parking map including the active area to an identified vehicle proximate to a location associated with the active area; A method comprising:

15. 15. The method of claim 14, wherein receiving the trajectory information includes receiving at least a start time and a stop time associated with the search vehicle searching for a parking spot in at least one of a parking lot, a parking garage, and on-street parking.

16. 16. The method of claim 15, wherein estimating the search time includes identifying the start time as when the search vehicle begins searching for the parking spot and the stop time as when the vehicle parks, including identifying the start time as at least one of: identifying when the vehicle begins a start and stop pattern; identifying when the vehicle circles the same geographic area; a distance to a destination meeting a threshold; and when the vehicle enters a parking area.

17. 15. The method of claim 14, wherein aggregating the observation time and the search time includes determining whether the search time meets the time threshold that indicates when the location has reached a level of parking availability that postpones finding available parking.

18. updating the parking map includes defining sub-regions in a geographic area that include the locations associated with each one of the sub-regions and applying a sliding time window to the observation times for the sub-regions to determine when an average time to park meets the parking threshold; updating the parking map includes identifying the active area as each one of the sub-areas that meets the parking threshold.

15. The method of claim 14.

19. providing the parking map includes communicating the parking map to the vehicle to cause the vehicle to actively sense available parking spaces in the active area and communicate the available spaces to facilitate parking by a following vehicle; providing the parking map including the active area conserves resources by activating a parking identification function for each one of the vehicles within the active area and disabling the parking identification function for each one of the vehicles not within the active area.

15. The method of claim 14.

20. providing the parking map includes communicating space information identifying locations of available parking spaces at the location according to information obtained from the location; updating the parking map includes analyzing the observed time in combination with historical data regarding parking in the sub-regions to determine whether each one of the sub-regions meets the parking threshold.

20. The method of claim 18.

Images