High-definition maps used in automated driving systems for autonomous vehicles

Abstract

To provide a method, system, and computer program concerning an automatic driving system in an autonomous vehicle, particularly, a high-precision map employed in the automatic driving system in the autonomous vehicle.SOLUTION: The method according to the invention generates and provide an indication to an autonomous vehicle regarding a confidence level for accuracy or quality of map data in which the indication is determined from observation data received from other vehicles.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to a method, a system, a computer program, etc., related to an automatic driving system in an autonomous vehicle. In particular, the present invention relates to a high precision map used in an automatic driving system in an autonomous vehicle. [Background technology]

[0002] Autonomous vehicles, sometimes called automated vehicles, typically include an Autonomous Driving System (ADS) that enables the vehicle to drive fully or partially autonomously. The ADS relies on two key sets of input data to maintain a model of the vehicle's environment: sensor-derived observations (SDOs) and high-definition (HD) maps.

[0003] SDOs are vehicle sensor-derived observations of the vehicle's current environment. Vehicle sensors can include both location sensors (e.g., GPS) and environmental sensors (e.g., cameras, RADAR, LIDAR). Often, these vehicle sensors are intelligent and have embedded perception capabilities to detect and classify geospatial objects, e.g., traffic signs. Vehicle sensors observe both stationary and dynamic objects.

[0004] HD maps are highly detailed 3D maps with a high level of accuracy suitable for use by an ADS to provide vehicles with sufficiently accurate information about the road environment so they can navigate effectively and safely. HD maps effectively extend a vehicle's field of view, enabling smoother, safer, and more efficient driving scenarios. As part of an ADS, HD maps can be utilized to fulfill a wide range of advanced driving applications. HD maps require highly accurate representations of road systems and their appurtenances, such as lane models that include lane markings, lane centerlines, and the geometry of road boundaries. Therefore, HD maps suitable for autonomous driving have a significantly higher level of accuracy compared to maps used in vehicle satellite navigation or smartphone map apps.

[0005] HD maps can be thought of as driving automation-relevant models of the geospatial reality of road systems, including abstractions of stationary objects and their relationships. Stationary objects are sometimes referred to as reality features, while their representations in HD maps are sometimes referred to as map features. Three geometric classes of map features are distinguished: point features (e.g., traffic signs), line features (e.g., road boundaries), and area features (e.g., road surface areas). Map features can have associated attributes, such as a speed limit associated with a road or lane, or a sign type associated with a traffic sign. In contrast to SDOs, HD maps contain features that represent only stationary objects, and the observations underlying map features in HD maps are historical (i.e., created in the past).

[0006] An HD map can be subdivided into tiles and layers. A map tile, for example, describes a rectangular map area containing map data related to that area of ​​the map. A map layer contains a subset of the available map data. For example, an HD map can include an HD roads layer, a speed limit layer, and a road check layer. The HD roads layer contains map data about arcs (representing junction areas and lane groups) and nodes (connecting the arcs). The map data in the speed limit layer describes speed limits. The road check layer contains map data representing driving automation limits. An HD map can include additional layers. In summary, HD map data is structured into layers of tiles.

[0007] As mentioned above, an autonomous vehicle's ADS uses both SDO and data from HD maps to model the vehicle's current environment. Therefore, the ADS needs to determine the extent to which it can rely on map features to accurately represent corresponding stationary objects. This raises the need for map quality meta-information that allows the in-vehicle logic to quantify the quality of stationary object representations present in the vehicle environment model.

[0008] The quality of HD maps is specified using quality indicators defined in the ISO 19157:13 standard (completeness, logical consistency, location accuracy, thematic accuracy, and temporal accuracy). The quality of HD maps depends on the time, quality, and quantity of the source data and the quality of the applied mapping process. Currently, the majority of source data for creating HD maps comes from high-quality survey vehicles. However, frequently surveying roads using survey vehicles to capture changes is economically impractical. Because real-world features change continuously for many reasons, and not all roads represented in an HD map are surveyed on the same day, it is practically impossible to provide an HD map in which all HD map features accurately reflect current reality. As discussed in International Publication Nos. 2017 / 021473, 2017 / 021474, 2017 / 021475, and 2017 / 021778, vehicle sensor data from ordinary passenger vehicles can also be used as source data for creating HD maps.

[0009] To operate safely, autonomous vehicles require reliable HD maps, as discussed above. Therefore, relevant reality changes should be quickly communicated to the automated vehicle via HD map updates. However, the time between a reality change and the delivery of the relevant HD map update to the vehicle can be significant. It takes time before either a reconnaissance vehicle visits the changed location and provides high-quality environmental sensor data, or before a regular passenger car can provide sufficiently moderate-quality environmental sensor-derived observations.

[0010] Typically, a content delivery network (CDN) uses known content delivery technologies and communication network infrastructure to deliver HD maps to HD map clients. The CDN content delivery model uses content caching storage facilities to ensure that content is close to HD map clients requesting specific map tiles while driving. This CDN approach reduces communication overhead and content delivery latency. It also means that relatively stable content can achieve a high cache hit rate, improving CDN efficiency.

[0011] This application seeks to improve upon current methods and systems related to HD maps used by ADS in autonomous vehicles. In particular, this application aims to provide methods and systems for better handling changes (or lack thereof) in real-world features and associated meta-information. Summary of the Invention

[0012] According to a first aspect of the present invention, there is provided a computer-implemented method in a server system, the server system storing HD map data representing a road system having a plurality of objects, the HD map data including a plurality of map features representing the plurality of objects of the road system, the server system further storing HD map metadata, the metadata including confidence levels in the HD map data for the plurality of map features, the HD map data and the metadata being provided for use by an automated driving system in an autonomous vehicle, the method comprising: receiving observation data of the road system, the observation data including one or more observations of the road system; and identifying one or more objects from the plurality of objects identified in the HD map data; identifying one or more map features in the HD map data that correspond to the one or more objects of the road system; generating updated metadata for the identified one or more map features based on the observation data to reflect an updated confidence level in the identified one or more map features compared to a respective confidence level of the identified one or more map features in the HD map metadata; and providing the updated metadata for use by the automated driving system, wherein the updated metadata is provided to the automated driving system independently of providing the HD map data.

[0013] In some embodiments of the first aspect, for each map feature of the identified map feature, if the observation data matches the map feature, generating updated metadata includes one or more of: increasing or maintaining the confidence level in the identified one or more map features; updating a confirmation date field in the metadata for the map feature to the date of the observation data; and updating a confirmation confidence field in the metadata for the map feature based on the confidence level associated with the observation data.

[0014] In some embodiments of the first aspect, for each map feature of the identified one or more map features, if the observation data is inconsistent with that map feature but the inconsistency is insufficient to satisfy a change map requirement for updating the HD map data, generating updated metadata includes lowering the confidence level for that map feature.

[0015] In some embodiments of the first aspect, for each map feature of the identified one or more map features, if the observation data is inconsistent with that map feature and the inconsistency is sufficient to satisfy a change map requirement for updating the HD map data, the method further includes using the observation data to determine changes to the object corresponding to that map feature, generating a map change feature describing the change in that map feature based on the determined changes to reflect the determined changes in the corresponding object, matching the map change feature with other map change features for the identified one or more features to form map change data, and providing the map change data for use by the automated driving system, wherein the map change data may be provided to the automated driving system independently of providing the HD map data. The map change data may be provided to the automated driving system along with providing the updated metadata.

[0016] According to a second aspect of the present invention, there is provided a server system, the server system storing HD map data representing a road system having a plurality of objects, the HD map data including a plurality of map features representing the plurality of objects of the road system, the server system further storing HD map metadata, the metadata including a confidence level in the HD map data for the plurality of map features, the HD map data and the metadata being provided for use by an automated driving system in an autonomous vehicle, the server system receiving observation data of the road system, the observation data including one or more observations of the road system, and one or more of the plurality of objects associated with the observation data. and identifying one or more map features in the HD map data that correspond to the one or more objects of the road system; generating updated metadata for the identified one or more map features based on the observation data to reflect an updated confidence level in the identified one or more map features compared to a respective confidence level of the identified one or more map features in the HD map metadata; and providing the updated metadata for use by the automated driving system, wherein the updated metadata is provided to the automated driving system independently of providing the HD map data.

[0017] In some embodiments of the second aspect, the one or more processors may be configured such that, for each map feature of the identified map feature, if the observation data matches the map feature, generating updated metadata includes one or more of: increasing or maintaining the confidence level in the identified one or more map features; updating a confirmation date field in the metadata for the map feature to a date of the observation data; and updating a confirmation confidence field in the metadata for the map feature based on a confidence level associated with the observation data.

[0018] In some embodiments of the second aspect, the one or more processors may be configured such that, for each map feature of the identified one or more map features, if the observation data is inconsistent with that map feature but the inconsistency is insufficient to satisfy a change map requirement for updating the HD map data, generating updated metadata includes lowering the confidence level for that map feature.

[0019] In some embodiments of the second aspect, the one or more processors may be configured to: for each map feature of the identified one or more map features, if the observation data is inconsistent with that map feature and the inconsistency is sufficient to satisfy a change map requirement for updating the HD map data, use the observation data to determine a change in the object corresponding to that map feature, generate a map change feature describing the change in that map feature based on the determined change to reflect the determined change in the corresponding object, match the map change feature with other map change features for the identified one or more features to form map change data, and provide the map change data for use by the automated driving system, wherein the map change data may be provided to the automated driving system independently of providing the HD map data. The map change data may be provided to the automated driving system along with providing the updated metadata.

[0020] In some embodiments of the first and second aspects, the HD map data and the HD map metadata can be based on at least sensor data from an HD mapping vehicle, and the observation data can be based on a data source other than the HD mapping vehicle.

[0021] In some embodiments of the first and second aspects, the observation data may include one or more of data from a sensor-equipped passenger vehicle, observation reports provided by humans such as vehicle users, and data from an earthquake information service provider.

[0022] In some embodiments of the first and second aspects, the updated confidence level may be associated with the data source of the observed data.

[0023] In some embodiments of the first and second aspects, the updated metadata may further reflect a rate of change over time to be applied to the updated confidence level in the identified one or more map features.

[0024] In some embodiments of the first and second aspects, the observation data may include a plurality of observations regarding a particular object, and the updated confidence level for the particular object may be based on a statistical confidence associated with the plurality of observations.

[0025] According to a third aspect of the present invention, there is provided a computer-implemented method on a client computer system in an autonomous vehicle, the client computer system comprising an automated driving system, the client computer system configured to receive and store HD map data representing a road system having a plurality of objects, the HD map data including a plurality of map features representing the plurality of objects of the road system, the client computer system further configured to receive and store HD map metadata, the metadata including a confidence level in the HD map data for the plurality of map features, the HD map data, and the metadata for use by the automated driving system, the method including: receiving updated metadata for one or more map features of the plurality of map features of the HD map data, the updated metadata being received independently of receipt of the HD map data; processing the updated metadata to identify updated map features, the updated map features being some of the one or more map features associated with a specified portion of the road system; and generating updated HD map data for the specified portion of the road system based on the updated metadata for the updated map features to enable use of the updated HD map data by the automated driving system.

[0026] In some embodiments of the third aspect, the method may further include distributing at least a portion of the updated HD map data to at least one electronic control unit in the vehicle.

[0027] In some embodiments of the third aspect, the method may further include sending a request for updated metadata to a server, the updated metadata being received from the server in response to the request. The request may be a request for updated metadata covering the same geographic area as the HD map data stored on the client computer system. Alternatively, the request may be a request for updated metadata covering a sub-area of ​​the geographic area covered by the HD map data stored on the client computer system. The request may indicate the sub-area by one of explicitly indicating the sub-area, indicating a proximity of the vehicle, or indicating the current location of the vehicle and a history of the vehicle's movements so that the server can determine the appropriate sub-area. Alternatively, in some embodiments, the request may be a request for updated metadata for a particular map feature among the plurality of map features.

[0028] In some embodiments of the third aspect, the method may further include receiving map change data describing changes to one or more map features of the plurality of map features of the HD map data, the map change data being received independently of receipt of the HD map data, the updated map features being further identified by processing the map change data to identify some of the one or more map features associated with the specified portion of the road system, and generating the updated HD map data being further based on the map change data regarding the updated map features.

[0029] According to a fourth aspect of the present invention, there is provided a client computer system for an autonomous vehicle, the client computer system comprising an automated driving system, the client computer system configured to receive and store HD map data representing a road system having a plurality of objects, the HD map data including a plurality of map features representing the plurality of objects of the road system, the client computer system further configured to receive and store HD map metadata, the metadata including a confidence level in the HD map data for the plurality of map features, the HD map data and the metadata for use by the automated driving system, the client computer system comprising one or more processors configured to: receive updated metadata for one or more map features of the plurality of map features of the HD map data, the updated metadata being received independently of receipt of the HD map data; process the updated metadata to identify updated map features, the updated map features being some of the one or more map features associated with a specified portion of the road system; and generate updated HD map data for the specified portion of the road system based on the updated metadata for the updated map features to enable use of the updated HD map data by the automated driving system.

[0030] In some embodiments of the fourth aspect, the one or more processors may be further configured to distribute at least a portion of the updated HD map data to at least one electronic control unit in the vehicle.

[0031] In some embodiments of the fourth aspect, the one or more processors may be further configured to send a request for updated metadata to a server, the updated metadata being received from the server in response to the request. The request may be a request for updated metadata covering the same geographic area as the HD map data stored on the client computer system. Alternatively, the request may be a request for updated metadata covering a sub-area of ​​the geographic area covered by the HD map data stored on the client computer system. The request may indicate the sub-area by one of explicitly indicating the sub-area, indicating a proximity of the vehicle, or indicating the current location of the vehicle and a movement history of the vehicle so that the server can determine an appropriate sub-area. Alternatively, in some embodiments, the request may be a request for updated metadata for a particular map feature among the plurality of map features.

[0032] In some embodiments of the fourth aspect, the one or more processors may be further configured to receive map change data describing changes to one or more map features of the plurality of map features of the HD map data, wherein the map change data is received independently of receipt of the HD map data, and wherein the updated map features are further identified by processing the map change data to identify some of the one or more map features associated with the specified portion of the road system, and wherein generating the updated HD map data is further based on the map change data regarding the updated map features.

[0033] In some embodiments of the third and fourth aspects, the specified portion of the road system may be a portion of the road system in the vicinity of the vehicle, the vicinity of the vehicle being determined based on a current position of the vehicle, and the vicinity of the vehicle may further be determined based on an expected direction of travel or area of ​​travel of the vehicle.

[0034] In some embodiments of the first through fourth aspects, the HD map data covers a specified geographic area and may include multiple layers, each layer including a different type of map data for the specified geographic area, and the HD map metadata and the updated metadata cover the same specified geographic area such that they can be processed as if they were layers of the HD map data.

[0035] In some embodiments of the first to fourth aspects, the size of the updated metadata may be one or more orders of magnitude smaller than the size of the HD map data.

[0036] According to a fifth aspect of the present invention, there is provided a computer program which, when executed by one or more processors, causes said one or more processors to perform a method according to the above-mentioned first aspect of the invention (or an embodiment thereof) or the above-mentioned third aspect of the invention (or an embodiment thereof), said computer program may be stored on a computer-readable medium. [Brief explanation of the drawings]

[0037] Embodiments of the present invention will now be described, by way of example, with reference to the accompanying drawings, in which: [Figure 1] FIG. 1 illustrates a schematic of a client-server system architecture according to one embodiment. [Figure 2] FIG. 2 shows a schematic of a server-side system for generating map change data. [Figure 3] FIG. 3 illustrates a schematic of a server-side system for generating updated metadata. [Figure 4a] , [Figure 4b] 4a and 4b show two examples of client-side systems in schematic form. [Figure 5] FIG. 5 shows a schematic diagram of the use of an online API server. [Figure 6]FIG. 6 illustrates schematically a server-implemented method for generating map change data. [Figure 7] FIG. 7 illustrates schematically a method implemented by a server for generating updated metadata. [Figure 8] FIG. 8 illustrates generally a client-implemented method for generating updated HD map data based on map change data for a specified portion of a road system. [Figure 9] FIG. 9 illustrates generally a client-implemented method for generating updated HD map data based on updated metadata for a specified portion of a road system. DETAILED DESCRIPTION OF THE INVENTION

[0038] Changing reality The geospatial reality associated with road systems is continuously changing. This change in reality has several causes: Changes in traffic regulations: For example, in March 2020, speed limits on Dutch highways will change from 120 / 130 km / h to 100 km / h during certain periods of the day. Relevant real-world changes include the addition, removal, or change of traffic signs, as well as the repainting of signs on the road surface. Wear and tear of road markings and pavement: This depends on the durability of the asphalt and road paint, weather conditions and intensity of use. Relevant real-world changes include road construction and / or resurfacing. • Changes in traffic volume: Such changes may cause the need to expand or modify the road network. Relevant real-world changes therefore include road construction. Precipitation: For example, rain or snow can cause dirty traffic signs and potholes in the pavement. Relevant real-world changes include traffic sign maintenance activities (e.g., cleaning), which involve the possibility of slight unintended changes in the orientation of signs, and roadworks to repair potholes in the pavement. Vandalism: For example, graffiti, stickers, and / or shooting can damage traffic signs. Related reality changes include replacing traffic signs. Earthquakes: Earthquakes can cause displacement and / or damage to roads, traffic signs, traffic lights, etc. Associated reality changes include changes in the position of real-world features and / or roadwork to repair damage.

[0039] Many real-world changes are spatially and temporally correlated, e.g., repainting road markings and changing traffic signs due to speed limit changes. Real-world changes may be periodic, e.g., repainting road markings as part of routine road maintenance. On highways, the periodic maintenance periodicity is typically once every 4-8 years. This means that 12.5-25% of the road network is repainted annually. Some real-world changes are more frequent than others, e.g., changing traffic signs due to speed limits is more frequent than replacing traffic signs due to vandalism.

[0040] Changes in real-world features occur at a rate of approximately 5-20% per year. This means that 5-20% of map features need to be updated per year. These changes are generally not distributed evenly; for example, during major road construction, substantial changes in real-world features may occur over a small area in a relatively short period of time. After such road construction, the rate of change over that same period may drop substantially.

[0041] Real-world change observations Observations of real-world change come from a variety of sources, including: ●High quality research vehicle. • A large number of conventional passenger vehicles equipped with both position and environmental sensors, in particular cameras, RADAR and / or LIDAR. • Active Community Input (ACI) which includes real-world observation reports provided by humans, especially vehicle users. • Geophysical information sources such as the USGS Earthquake Hazards Program, available at https: / / earthquake.usgs.gov / fdsnws / event / 1 / .

[0042] Reality change observations obtained from survey vehicles automatically have a high quality index associated with them. The quality index associated with other data sources is reduced (e.g., depending on the number of independent observations of a particular reality change, the precision / accuracy of the observations, the type of observation, etc.).

[0043] overview This application addresses techniques for providing HD map clients with map features that provide an accurate and current representation of real-world features.

[0044] Currently, HD map compilers can use real-world observations from, for example, survey vehicles or passenger cars when generating new HD map data. The new HD map data is delivered to HD map clients via a CDN. This means that even very small changes in real-world features trigger the compilation and delivery of large amounts of map data. This requires significant map compilation and map delivery resources. The overhead can result in change aggregation delays when providing new map data. Therefore, new HD map data (i.e., HD map features) are delivered intermittently from the server side (where observation data is received) to the client side (i.e., the HD map client in the autonomous vehicle) when an update is deemed necessary.

[0045] Additionally, including HD map quality metadata in HD map features increases the size of the HD map data (although this may be relatively small). It also requires compiling new HD map data when the HD map quality metadata is no longer deemed sufficiently accurate. This means that inaccuracies in a small portion of the map data result in the compilation and distribution of substantially larger amounts of data. This increases map compilation and map distribution resources. It also results in a relatively static representation of the HD map quality metadata, which may use some predetermined aging for the confidence indicators included in the HD map quality metadata.

[0046] According to the present application, map change data is generated on the server side and distributed to HD map clients independently of HD map features (i.e., independently of the HD map data itself). This significantly reduces the overhead associated with distributing updates. On the client side, the map change data is received and processed to update relevant portions of the (old) HD map data stored in the vehicle. This may include creating, updating, or removing HD map features and / or associated attributes. The updated map data is then used by the automated driving system.

[0047] Similarly, according to the present application, updated metadata (including updated confidence levels for one or more map features) is generated on the server side and distributed to HD map clients independently of the HD map features (i.e., independently of the HD map data itself). Again, this significantly reduces the overhead associated with distributing updates. On the client side, the updated metadata is received and processed to update the relevant portions of the (older) HD map data stored in the vehicle. The updated map data is then used by the automated driving system. Having the updated metadata as part of the updated map data means that the automated driving system can determine how best to weight the (older) HD map data and the (current) SDO data when driving.

[0048] Clearly, these two aspects of the present application (i.e., map change data and updated metadata) can be combined, provided that any map feature change has an associated metadata update. However, it is also contemplated that map feature changes can occur in the absence of metadata updates, and metadata updates can occur in the absence of map feature changes.

[0049] System Architecture 1 illustrates a schematic diagram of a system architecture 100 according to one embodiment. The server side of the architecture 100 comprises an HD map server 110, and the client side of the architecture 100 comprises a client computer system 150 including an HD map client 160 coupled to an electronic control unit (ECU) platform 170. The HD map client is further coupled to an HD map application 180 via a map feature adjustment module 190. The client side of the architecture 100 can be considered a client computer system (including one or more computers) within an autonomous vehicle. The autonomous vehicle has an ADS.

[0050] The HD map server 110 is a server system including one or more servers. The HD map server 110 includes a first storage medium 120 (e.g., a database) that stores map source data related to a plurality of objects in a road system. The first storage medium is coupled to a map generation module 122 configured to generate map data based on the map source data. The map generation module 122 is coupled to a map compiler 124 configured to compile the map data into a plurality of map features representing the plurality of objects and associated quality indicators. The map compiler 124 is coupled to both a map data service 126 and a map metadata service 128. The map data service 126 is configured to provide digital HD map data including the plurality of map features. As described above, the HD map data may be structured into layers of tiles. The map metadata service 128 is configured to provide map metadata including quality indicators (or confidence levels) associated with the plurality of map features in the HD map data. The HD map data and map metadata are suitable for use by an automated driving system in an autonomous vehicle.

[0051] The HD map server 110 further includes a second storage medium 142 (e.g., a database) that stores reality change observations (values) for multiple objects in the road system. The reality change observations are received from the combined reality change observation manager 140. The second storage medium 142 is also coupled to a reality change detection module 144 configured to analyze the reality change observations to detect reality changes in one or more objects in the road system that satisfy change map requirements for updating the HD map data. The reality change detection module 144 can generate reality change tokens that represent the detected reality changes. The reality change detection module 144 is coupled to a map change compiler 146 configured to compile the detected reality changes by determining map features affected by the detected reality changes (i.e., map features associated with one or more changed objects). The map change compiler 146 generates map change data describing changes in the associated map features to reflect the detected reality changes in one or more objects in the road system. The map change data consists of changes in one or more map features corresponding to one or more objects in the road system where changes were observed. In essence, map change data can be thought of as capturing the "what," "where," and "when" of reality changes. The map change compiler 146 is coupled to a map change service 148 that is configured to provide the map change data.

[0052] The distribution mechanism for map change data (i.e., map change service 148) is separate from the distribution mechanism for HD map features (i.e., map data service 126). This allows updates to map change data to occur much faster without requiring simultaneous updates to HD map features. Because map change data describes changes to HD map features, each map feature change describes the creation, modification, or removal of an HD map feature.

[0053] In the embodiment of FIG. 1 , HD map client 160 comprises HTTPS client 161, client library 162, map data validator 163, persistent map data cache 164, map interface adapter 165, and controller 166. However, it will be understood that the functionality of at least some of these modules may be combined in alternative implementations. HTTPS client 161 is configured to receive HD map data (i.e., map features) from map data service 126. HTTPS client 161 is further configured to receive map metadata from map metadata service 128. HTTPS client 161 is further configured to receive map change data from map change service 148. Each of these sets of data may be received independently of one another, such that each set of data can be considered to have its own communication channel. Client library 162 is coupled to HTTPS client 161, map data validator 163, persistent map data cache 164, and map interface adapter 165. Map data validator 163 is configured to validate any received map data (e.g., HD map data, map change data, and / or map metadata). Once validated, the received map data is stored in persistent map data cache 164.

[0054] The controller 166 of the HD map client 160 is coupled to the ECU platform 170. The map interface adapter 165 is coupled to the HD map application 180 via the map feature adjustment module 190. The map interface adapter 165 is configured to provide various data to the map feature adjustment module 190. For example, the map interface adapter 165 can provide HD map data (i.e., map feature data stored in the persistent map data cache 164) and actual changes (i.e., map change data) to the map feature adjustment module 190. The map feature adjustment module 190 is configured to process the received data to identify map features in the map change data associated with the specified portion of the road system. The map feature adjustment module 190 then generates updated HD map data for the specified portion of the road system. The updated HD map data includes relevant portions of the HD map data updated according to the map change data. The map feature adjustment module 190 is configured to provide the updated HD map data to the HD map application 180 as a map client service. The updated HD map data is configured for use by an ADS of an autonomous vehicle associated with the client side of architecture 100. The ADS is embodied by modules such as controller 166, ECU platform 170, and HD map application 180, which are not explicitly shown in FIG.

[0055] Generate initial HD map data and associated HD map metadata The initial HD map data is generated by the HD map server 110 using map source data stored on the first storage medium 120. The initial HD map data is generated primarily based on data collected by an HD mapping vehicle equipped with high-quality position sensors and vehicle environment sensors. The collected data is then stored on the first storage medium 120. As described above with reference to FIG. 1, the map generation module 122 and the map compiler 124 generate the HD map data and make it available via the map data service 126. Similarly, the map generation module 122 and the map compiler 124 generate corresponding HD map metadata and make it available via the map metadata service 128. The quality index associated with the data collected by the HD mapping vehicle is typically very high (typically 100%), which is reflected in the HD map metadata associated with the initial HD map data. Each map feature and attribute in the HD map data has an associated observation date, which is the date when the HD mapping vehicle collected the underlying data. The observation date forms part of the HD map metadata. The HD map metadata also includes a verification date and verification confidence for each map feature or attribute. The Confirmation Date is the confirmation date of the observation and is set to the same date as the observation date of the HD mapping vehicle data. The Confirmation Confidence reflects the confidence level in the underlying data associated with the Confirmation Date. Therefore, the Confirmation Confidence value is set to a value that represents 100% confidence for the HD mapping vehicle data.

[0056] Generate map change data FIG. 2 illustrates portions 200 of the HD map server 110 responsible for generating map change data: the reality change observation manager 140, the second storage medium 142, the reality change detection module 144, the map change compiler 146, and the map change service 126. While FIG. 2 also illustrates reality change sources 210, which are data sources from which reality change observations are received, it will be understood that these data sources 210 do not actually form part of the reality change map server 200 but instead provide input to the reality change map server 200. The data sources 210 used to generate map change data are generally secondary sources of data (i.e., data sources other than the HD mapping vehicle). Examples of secondary sources of data are sensor-equipped passenger vehicles, observation reports provided by people (e.g., vehicle users), and earthquake information service providers. Other examples include satellite data sources, geophysical data sources, and road construction information sources. 1, the reality change observation manager 140 collates the data collected from all these secondary sources 210 and stores it all as reality change observations in the second storage medium 142. The reality change detection module 144 and the map change compiler 146 then generate the map change data and make it available via the map change service 126.

[0057] 6, the map change data may be generated according to a computer-implemented method 600 on a server system (e.g., HD map server 110). The server system stores HD map data representing a road system with multiple objects (see, e.g., HD map data made available via map data service 126). The HD map data includes multiple map features representing multiple objects in the road system. The HD map data is suitable for use by an automated driving system in an autonomous vehicle.

[0058] The method 600 includes a first step S602 of receiving observation data of a road system. The observation data (e.g., reality change observations stored in the second storage medium 142) includes one or more observations of the road system. As described above, the observation data may be received via the reality change observation manager 140.

[0059] The method 600 includes a second step S604 of using the observation data to determine a change in one or more of the objects. As described above, the change in the one or more objects may be determined by the reality change detection module 144.

[0060] The use of observational data to determine changes in one or more objects is typically based on a small number of reality change observations stored in the second storage medium 142. However, the changes may also be statistical in nature and based on a larger number of historical reality change observations.

[0061] Using the observational data to determine changes in one or more objects may include determining changes in absolute position and / or relative position and / or geometry and / or type and / or presence of one or more objects.

[0062] Using the observation data to determine a change in one or more objects may include using the observation data to determine a change in one or more objects that satisfies a change map requirement for updating the HD map data. For example, the determined change may involve a change in position and / or relative position and / or geometry above a threshold level (e.g., movement of an object by more than 10 cm). Alternatively, any change including the removal of an object or the addition of a new object may be considered to satisfy the change map requirement. Similarly, a change in object type may be considered to satisfy the change map requirement; for example, a previously identified object was considered to be a road sign, but the observation data now suggests it is something other than a road sign.

[0063] As described above, reality change detection module 144 can generate reality change tokens that represent detected reality changes. Reality change tokens can be based on a small number of reality change observations, but can also describe reality changes derived from a large amount of (historical) reality change information.

[0064] The method 600 includes a third step S606 of identifying one or more map features in the HD map data that correspond to one or more objects in the road system. As described above, the one or more map features may be identified by the map change compiler 146.

[0065] Changes in one or more objects may be involved. For example, a change may indicate a 10 cm shift of numerous objects (roads, signs, etc.) in a given area due to an earthquake. As mentioned above, there are three geometric classes of map features: point features (e.g., traffic signs), line features (e.g., road boundaries), and area features (e.g., road surface areas). Therefore, changes affecting all objects in a given area can be efficiently represented using area map features. This means that the number of changed objects (i.e., the number of one or more objects) can be greater than the number of one or more features identified. Clearly, this is more efficient in terms of the amount of data needed to represent the changes.

[0066] The method 600 includes a fourth step S608 of generating, based on the determined changes and the identified one or more map features, map change data describing changes to the one or more map features to reflect the determined changes to the one or more objects. As mentioned above, the map change data may be generated by the map change compiler 146.

[0067] As described above, the map change data consists of one or more map change features (corresponding to each of one or more identified map features), each of which describes the creation, modification, or removal of an HD map feature or multiple HD map features (e.g., HD map features within an area).

[0068] As described above, area-related reality change information can be compactly represented by area map feature changes. Thus, such changes can be delivered to HD map clients at low cellular network costs. Once received by the HD client, the area map feature changes can still be processed to associate the changes with relevant portions of the road system to enable transfer of this information over the vehicular network using a vehicle horizontal protocol such as ADASIS V2 / V3.

[0069] The map change data may include one or more replacement map features (e.g., X') to directly replace one or more map features (e.g., X) in the HD map data, thereby describing changes to the one or more map features. In this example, the map change data effectively provides a more up-to-date version of the one or more map features. Alternatively, the map change data may include changes to one or more map features relative to the HD map data stored on the server system, thereby describing changes to the one or more map features. In other words, for a map feature X in the HD map data, the map change data may indicate a change ΔX that can be applied to the original map feature X to provide an updated map feature X', where X' = X + ΔX.

[0070] The map change data may include new or updated attributes of one or more map features. The new or updated attributes may include one or more new or updated absolute and / or relative positions and / or geometric shapes and / or classes and / or cryptographic hashes of one or more map features. For example, consider a map feature identified in the HD map data as a road sign, but the original HD mapping vehicle data was unable to determine the class of the road sign (e.g., because it was partially obscured during the mapping process). In this case, a new attribute defining the class of the road sign may be provided as part of the map change data. In the case of a new or updated cryptographic hash, this may be an encryption of the map change data for the particular changed feature, which may be used for fault-tolerant map implementations.

[0071] HD map data covers a specified geographic area. As previously mentioned, HD map data can include multiple layers, with each layer containing a different type of map data for the specified geographic area. In this scenario, map change data can be generated to cover the same specified geographic area so that it can be processed as if it were a layer of HD map data. The map change data is an application-relevant model of geospatial reality changes and includes an abstraction of those reality changes. The reality changes represented in the map change data are directly or indirectly related to the geospatial object representations present in the HD map data. Therefore, it is technically practical to implement the map change data as a layer to the HD map data that can be created, updated, and distributed separately. For example, this type of layer implementation simplifies client-side processing of the data.

[0072] The method 600 includes a fifth step S610 of providing map change data for use by the automated driving system, the map change data being provided to the automated driving system independently of providing HD map data. In this manner, the map change service 148 may be provided with map change data independently of providing HD map data by the map data service 126 and independently of providing HD map metadata by the map metadata service 128.

[0073] Method 600 may further include distributing the map change data to one or more client computers. The map change data may be distributed by map change service 148 independently of the distribution of HD map data by map data service 126 and independently of the distribution of HD map metadata by map metadata service 128.

[0074] In one example, prior to distribution, the map change data may be processed by the server system to include only map change data associated with a specified portion of the road system. In other words, only a subset of the map change data (i.e., the portion associated with the specified portion of the road system) is sent to a particular client computer. This transmission may occur in response to a request from the particular client computer. This is a "pull" data distribution method for map change data, as opposed to a "push" data distribution method that sends data to all client computers as it becomes available (such as the TomTom AutoStream map distribution system). The request may be for map change data covering a subarea of ​​the geographic area covered by the map change data. The request may indicate the subarea by explicitly indicating the subarea. Alternatively, the request may indicate the subarea by indicating the proximity of a vehicle associated with the request. In a further alternative, the request may indicate the subarea by indicating the subarea according to the vehicle's current location and vehicle movement history, allowing the server system to determine the appropriate subarea. In this case, method 600 further includes determining the subarea based on the current location and movement history in response to receiving the request. In another example, the request may be for map change data relating to a particular map feature of a plurality of map features.

[0075] With regard to the "pull" distribution of map change data discussed above, FIG. 5 schematically illustrates a suitable system architecture including a map server 110, a map client 160, and an API server 500 (such as the TomTom MC API). Both the map server 110 and the API server 500 may be considered part of the same server system. While the map server 110 and the API server 500 are shown as different servers in FIG. 5, it will be understood that they may actually be embodied in a single server. Under a "push" distribution system, the map server 110 may distribute (510) map change data to one or more map clients 160 as the map change data becomes available. Under a "pull" distribution system, the map server 110 may in turn send (512) map change data to the API server as the map change data becomes available, and each map client 160 may request (514) map change data from the API server as and when it is needed. In response to such a request, the relevant map change data may be sent (514) back to the requesting map client 160.

[0076] As described above, HD mapping vehicles can only make intermittent observations of a given road system object. Despite increased HD map update frequency, there may still be a significant time between a real change and the availability of new HD map data. Meanwhile, many sensor-equipped passenger vehicles may observe the same object. Therefore, it will be appreciated that real change observations stored in the second storage medium 142 for a given object are generally more current (i.e., more up-to-date) than the HD mapping vehicle data stored in the first storage medium 120 for the same object. Furthermore, the size of the map change data is generally orders of magnitude smaller than the size of the HD map data. Therefore, map change data can be generated and made available relatively frequently compared to the HD map data and associated HD map metadata. Therefore, method 600 can make available map change data before HD map updates of sufficient quality can be delivered. In other words, the time between a real change and the delivery of the associated real change information to vehicles is typically shorter according to method 600. Thus, autonomous vehicles can recognize changes in reality immediately after they are detected and act on them appropriately, for example by disabling automated features or by adopting a conservative driving course of action.

[0077] As noted above, the map change data can be thought of as including one or more map feature changes. In other words, the map change data consists of a bundle of map feature changes for each of one or more identified map features. Some examples of map feature changes, including associated map attribute changes, are provided below.

[0078] In a first example, consider the impact of a particular earthquake. The area near the center of the earthquake is divided into subareas, each with an associated map attribute change and confidence level. The subareas are area features within the map change data. A first map attribute change for one of the subareas may state that "roads in the area may be damaged" and / or "roads in the area may have shifted by more than 10 cm." A second map attribute change for that subarea may indicate a 70% confidence level. A third map attribute change for that subarea may indicate a time period for the change that is between January 12, 2020 and January 15, 2020.

[0079] In a second example, consider a change in the speed limit for a particular stretch of road. The map attribute change is associated with an existing feature of the HD map, i.e., typically part of a lane group (e.g., part of a lane in a lane group). The map attribute change can indicate that the speed limit has decreased with an associated confidence level of 70%.

[0080] In a third example, consider the replacement of a traffic sign. Based on a large amount of historical observations, it is known that a traffic sign replacement leads to 1% of the replaced traffic signs along roads of a particular road class in the Netherlands changing their position and orientation. This information can be captured as an area map feature change in the map change data. Since the age of the HD map data is known (e.g., based on the observation date given in the HD map metadata), the confidence level associated with the relevant traffic sign map feature can be adjusted (downward) to more closely reflect the current reality. This is closely related to the generation of updated metadata, which is described in the next section.

[0081] The server system may further store HD map metadata, the metadata including confidence levels in the HD map data for multiple map features. The map change data may also have varying degrees of specificity and typically have an associated confidence indication. As discussed in the Overview section, generating the map change data may involve generating updated metadata. In this case, method 600 further includes (a) generating updated metadata for the identified one or more map features based on the observation data to reflect updated confidence levels for the identified one or more map features in the map change data compared to respective confidence levels for the identified one or more map features in the HD map metadata, and (b) providing the updated metadata for use by the automated driving system, the updated metadata being provided to the automated driving system independently of providing the HD map data.

[0082] The map change data and updated metadata may be generated and provided in tandem (i.e., effectively simultaneously) for the same observation data. Subsequently, method 600 may further include distributing the map change data and updated metadata to one or more client computer systems. The distribution of the map change data and updated metadata may occur together. Distributing together may include simultaneous distribution over different communication channels or distribution together over the same communication channel.

[0083] The observation data may include multiple observations about a particular object, in which case an updated confidence level for the particular object may be based on a statistical confidence associated with the multiple observations, meaning that statistical reality change information may be applied by the vehicle to continuously adjust the confidence of the map data relative to reality.

[0084] A more detailed description of generating updated metadata follows in the section entitled "Generating Updated Metadata."

[0085] Similar to the method 600 described above with reference to Figure 6, the present application also contemplates a server system configured to perform the method (see, e.g., Figures 1 and 2). Corresponding computer programs and computer-readable media storing computer programs are also contemplated.

[0086] Generate updated metadata In addition to generating map change data, the HD map server 110 can be used to generate updated metadata. Despite the increasing frequency of HD map data updates, there can still be significant time between updates. Thus, the HD map data and HD map metadata used by an autonomous vehicle can become significantly outdated. This application proposes using more recent observation data to provide updated metadata related to the existing HD map data used by the vehicle. This allows the vehicle to determine the quality of the HD map data when it relates to current reality, as opposed to the quality of the HD map data when it relates to historical reality.

[0087] The following table provides exemplary metadata fields that may be updated in accordance with the present application. These fields are exemplary and are not intended to be limiting in any way.

[0088] [Table 1]

[0089] The quality indices in the above table are simple integers, thus allowing for a compact representation of map quality meta-information that allows for efficient use of the cellular network (for map updates).

[0090] Figure 3 shows a portion 300 of the HD map server 110 that is responsible for generating updated metadata, i.e., the first storage medium 120 and the second storage medium 142. Figure 3 also depicts a third storage medium 310 that stores map quality associations, a map quality metadata compiler 312, and a map quality metadata service 314. These additional elements of Figure 3 are also present in the HD map server of Figure 1 but have been omitted from that figure for simplicity.

[0091] As described above, the first storage medium 120 stores map source data for multiple objects in the road system, and the second storage medium 142 stores actual change observations for the multiple objects in the road system. The actual change observations can include observations indicating that an actual change has occurred and observations indicating that an actual change has not occurred. The third storage medium 310 (e.g., a database) stores map quality associations that may indicate confidence levels to be associated with different sources of data stored in the first and second storage media 120, 142. The map quality associations may also indicate rates of change in confidence levels applied to different data sources over time. The three storage media 120, 142, 310 are coupled to a map quality metadata compiler 312 configured to compile updated metadata for one or more map features to reflect updated confidence levels for one or more map features compared to the respective confidence levels for the same map features in the HD map metadata. The compilation takes into account the map quality associations for various sources of input data. The map-quality metadata compiler 312 is coupled to a map-quality metadata service 314 configured to provide updated metadata.

[0092] 7, the updated metadata may be generated according to a computer-implemented method 700 on a server system (e.g., HD map server 110 or map-quality metadata server 300). The server system stores HD map data representing a road system having a plurality of objects (see, e.g., HD map data made available via map data service 126). The HD map data includes a plurality of map features representing the plurality of objects in the road system. The server system further stores HD map metadata (see, e.g., HD map metadata made available via map metadata service 128). The HD map metadata includes confidence levels in the HD map data for the plurality of map features. The HD map data and metadata are suitable for use by an automated driving system in an autonomous vehicle.

[0093] At least one map feature of the plurality of map features may have one or more associated attributes, and the HD map metadata of the at least one map feature may include a confidence level in the one or more attributes.

[0094] The confidence level may relate to the level of accuracy associated with the data, for example, because HD mapping vehicles make observations with a high level of accuracy, the level of confidence in the associated map features will generally be higher than for map features derived from less accurate data sources.

[0095] The method 700 includes a first step S702 of receiving observation data of a road system, the observation data including one or more observations of the road system.

[0096] The HD map data and HD map metadata may be based on at least sensor data from the HD mapping vehicle (i.e., map source data in the first storage medium 120), and the observation data may be based on data sources other than the HD mapping vehicle (i.e., reality change observations in the second storage medium 142).

[0097] The observation data (i.e., the reality change observations in the second storage medium 142) may include one or more of data from sensor-equipped passenger vehicles, observation reports provided by humans such as vehicle users, and data from earthquake information service providers.

[0098] The method 700 includes a second step S704 of identifying one or more objects of the plurality of objects associated with the observation data. The one or more objects may be identified by the map-quality metadata compiler 312.

[0099] The method 700 includes a third step S706 of identifying one or more map features in the HD map data that correspond to one or more objects in the road system. The one or more features may be identified by the map-quality metadata compiler 312.

[0100] The method 700 includes a fourth step S708 of generating updated metadata for the identified one or more map features based on the observation data to reflect an updated confidence level in the identified one or more map features compared to a respective confidence level for the identified one or more map features in the HD map metadata. As described above, the updated metadata may be generated by the map-quality metadata compiler 312.

[0101] The updated confidence level may be associated with the data source of the observation data, which may be accomplished by referencing map quality associations stored in the third storage medium 310, as described above.

[0102] The updated metadata may also reflect a rate of change over time to be applied to the updated confidence level in the identified one or more map features. In other words, the updated metadata indicates potential changes as a function of elapsed time relative to the time of observation of the identified one or more map features.

[0103] The observation data may include multiple observations for a particular object, in which case the updated confidence level for the particular object may be based on the statistical confidence associated with the multiple observations.

[0104] Generating the updated metadata may be further based on HD map metadata associated with the HD map data (ie, the latest HD map data provided by the map data service 126).

[0105] The HD map data covers a specified geographic area. As previously mentioned, the HD map data can include multiple layers, with each layer including a different type of map data for the specified geographic area. In this scenario, the HD map metadata and the updated metadata cover the same specified geographic area so that they can be processed as if they were layers of the HD map data. The HD map data is an application-relevant model of geospatial reality and includes abstractions of real-world objects. The updated metadata is directly or indirectly related to one or more features represented in the HD map data. Therefore, it is technically practical to implement the updated metadata as a layer on the HD map data that can be created, updated, and distributed separately. For example, this type of layer implementation facilitates simpler client-side processing of the data.

[0106] For each map feature of one or more identified map features, the observed data is associated with that map feature. MatchIn this case, generating updated metadata may include one or more of: (a) increasing or maintaining a confidence level in one or more identified map features; (b) updating a confirmation date field in the metadata for the map feature to the date of the observation data; and (c) updating a confirmation confidence field in the metadata for the map feature based on the confidence level associated with the observation data. This describes a way to address situations where reality has not changed. In this case, confirmation is generated that the map feature still reflects reality. Periodically (with a frequency that depends on typical reality change behavior), these feature-related and attribute-related confirmations can be delivered via updated metadata, e.g., updating the confirmation date and confirmation confidence. The confirmation information can be taken into account by the autonomous vehicle in determining feature and attribute quality. If the observation data has sufficiently high quality, the confirmation confidence may be updated to 100%. In such a case, the observation date is also updated. The confirmation date indicates the most recent date of observation data that confirmed the map feature still accurately represents the associated object in the road system. The confirmation confidence indicates the confidence level associated with the observation data that confirmed the map feature still accurately represents the associated object in the road system. As noted in the previous table, there may be several different confirmation confidence fields associated with a given map feature or attribute. Additionally, if no confirmation data is present, the confirmation date and confirmation confidence may be null fields.

[0107] Alternatively, the observed data may be related to the map features. Contradictory (inconsistent, inconsistent) ,The discrepancy is due to the change map ,requirements for updating HD map data. EnoughIn this case, method 700 may further include: (a) using the observation data to determine (determine) a change in the object corresponding to the map feature; (b) based on the determined change, generating a map change feature describing the change in the map feature to reflect the determined change in the corresponding object; (c) matching the map change feature with other map change features for the identified one or more features to form map change data; and (d) providing the map change data for use by the automated driving system, where the map change data is provided to the automated driving system independently of providing the HD map data. In other words, this includes a combination of updated metadata and change map data. This describes how to handle situations where the reality has changed. Generally, change map data is provided only when a change is provided that is large enough (or sufficiently certain) to warrant a change. In this case, the change information is generated and distributed by the map change data described in the previous section. The autonomous vehicle cannot rely on features / attributes in the HD map data that are sufficiently clear that the associated reality has changed. After a reality change occurs, there may be sufficient sensor-derived observations available to provide associated map change data (e.g., via map change service 148). This map change data may be of a quality level associated with the crowd-sourced observations, thus associating an appropriate quality index for the crowd-sourced data. Subsequently, after an HD mapping vehicle visits the changed location, a new version of the HD map data may be compiled (e.g., again by map compiler 124) based on data from the HD mapping vehicle, thus associating an appropriate quality index (e.g., 100%) for the HD mapping vehicle data. The map change data and updated metadata may be generated and provided in tandem (i.e., effectively simultaneously) for the same observation data. Subsequently, method 700 may further include distributing the map change data and updated metadata to one or more client computer systems.The distribution of the map change data and the updated metadata may occur together, which may include simultaneous distribution over different communication channels or distribution together over the same communication channel.

[0108] A further alternative is to use observation data in conjunction with the map features. contradictory However, there are discrepancies in the HD map data to meet the changing map requirements. Insufficient If the map feature is not updated (i.e., map change data is not generated for that map feature), generating updated metadata may include lowering the confidence level in that map feature. Thus, if the change is not large enough (or not certain enough) to warrant a change, change map data is not generated and instead the updated metadata may be used to lower the confidence level in the associated map feature.

[0109] The method 700 includes a fifth step S710 of providing updated metadata for use by the automated driving system, the updated metadata being provided to the automated driving system independently of providing the HD map data. As described above, the updated metadata may be provided by the map-quality metadata service 314.

[0110] As described above, an HD mapping vehicle can only make intermittent observations of a given road system object. Meanwhile, many sensor-equipped passenger vehicles can observe the same object. These observations may indicate that the object is still well represented by map features in the HD map data, or conversely, may indicate that the object is no longer well represented by map features in the HD map data. Thus, it will be appreciated that reality change observations stored in the second storage medium 142 for a given object are generally more current (i.e., more up-to-date) than the HD mapping vehicle data stored in the first storage medium 120 for the same object. Furthermore, the size of the updated metadata is generally orders of magnitude smaller than the size of the HD map data. Therefore, updated metadata can be generated and made available relatively frequently compared to the HD map data and associated HD map metadata. Thus, method 700 can make available updated metadata well before HD map updates of sufficient quality can be distributed. Thus, an autonomous vehicle can become aware of updated metadata immediately after a relevant observation is made (e.g., the autonomous vehicle can be provided with confirmation to avoid growing uncertainty over time even in the absence of new map updates) and can act on them appropriately, for example, by disabling / enabling automated features or by adopting a more or less conservative driving course of action.

[0111] Method 700 may further include distributing the updated metadata to one or more client computers. The updated metadata may be distributed by map-quality metadata service 314 independently of the distribution of HD map data by map data service 126 and independently of the distribution of HD map metadata by map metadata service 128.

[0112] In one example, prior to distribution, the map update metadata is processed by the server system to include only update metadata associated with a specified portion of the road system. In other words, only a subset of the updated metadata (i.e., the portion related to the specified portion of the road system) is sent to a particular client computer. This transmission can occur in response to a request from a particular client computer. This is a "pull" data distribution method for map change data, as opposed to a "push" data distribution method that sends data to all client computers as it becomes available (such as the TomTom AutoStream map distribution system). See FIG. 5 and the above discussion regarding implementations of "push" and "pull" distribution systems. The request may be for updated metadata covering a subarea of ​​the geographic area covered by the updated metadata. The request may indicate the subarea by explicitly indicating the subarea. Alternatively, the request may indicate the subarea by indicating the proximity of the vehicle associated with the request. In a further alternative, the request may indicate the subarea by the vehicle's current location and vehicle movement history, allowing the server system to determine the appropriate subarea. In this case, method 700 further includes, in response to receiving the request, determining the sub-area based on the current location and the movement history. In another example, the request may be a request for updated metadata regarding a particular map feature of the plurality of map features.

[0113] Similar to the method 700 described above with reference to Figure 7, the present application also contemplates a server system configured to perform the method (see, e.g., Figures 1 and 3), as well as a corresponding computer program and a computer-readable medium storing the computer program.

[0114] Client processing of map change data The client side of the system has already been described to some extent with reference to client computer system 150 of FIG. 1 . For example, map interface adapter 165 can provide HD map data (i.e., map feature data stored in persistent map data cache 164) and actual changes (i.e., map change data) to map feature adjustment module 190. Map feature adjustment module 190 is configured to process the received data to identify map features in the map change data associated with the specified portion of the road system. Map feature adjustment module 190 generates updated HD map data for the specified portion of the road system. The updated HD map data includes relevant portions of the HD map data updated according to the map change data. Map feature adjustment module 190 is configured to provide the updated HD map data to HD map application 180 as a map client service. The updated HD map data is configured to be used by an ADS of an autonomous vehicle associated with the client side of architecture 100. Although not explicitly shown in FIG. 1 , the ADS is embodied by modules such as controller 166, ECU platform 170, and HD map application 180. Further details will now be described with reference to Figures 4a and 4b.

[0115] FIG. 4 a illustrates an embodiment in which multiple HD map applications 180 are associated with the same map feature adjustment module 190 .

[0116] FIG. 4b illustrates an alternative embodiment in which each ECU platform 170 in an autonomous vehicle has its own associated map feature adjustment module 190 and HD map application 180. For example, FIG. 4b depicts a first ECU platform 170a having a first map feature adjustment module 190a and a first HD map application 180a, and a second ECU platform 170a having a second map feature adjustment module 190a and a second HD map application 180a. Such a configuration may be advantageous when different ECU platforms 170 require access to different areas of map data (i.e., when the designated portions of the road system are different for the first and second ECUs 170a, 170b). For example, a first ECU may be associated with automated parking, which requires access to a fairly localized area of ​​map data surrounding the vehicle. In contrast, a second ECU may be associated with automated driving (lane control) on a motorway, which requires access to a wider area of ​​the road ahead of the vehicle.

[0117] 8, updated HD map data may be generated according to a computer-implemented method 800 on a client computer system (e.g., client computer system 150). The client computer system comprises an automated driving system. The client computer system is configured to receive and store HD map data representing a road system having a plurality of objects (see, e.g., HD map data made available via map data service 126). The HD map data includes a plurality of map features representing a plurality of objects in the road system. The HD map data is suitable for use by the automated driving system.

[0118] The method 800 includes a first step S802 of receiving (e.g., by the HTTPS client 161) map change data describing changes to one or more map features of a plurality of map features of the HD map data. The map change data is received independently of receiving the HD map data.

[0119] The method 800 includes a second step S804 of processing the map change data (e.g., by the map feature adjustment module 190) to identify updated map features that are some of the one or more map features associated with the specified portion of the road system.

[0120] In particular, this processing step may occur well after the map change data is received (e.g., in a "push" delivery model for map change data), or, if the map change data is received in response to a request from a client computer system (i.e., in a "pull" delivery model), the processing step likely follows directly from receipt of the requested map change data.

[0121] The specified portion of the road system may be a portion of the road system near the vehicle, and the vehicle's proximity may be determined based on the vehicle's current location. The vehicle's proximity may further be determined based on the vehicle's expected direction of travel or travel area. In other words, identifying the portion of the map change data related to the vehicle's proximity allows the horizon protocol (e.g., (ADASIS V2, V3)) to properly process the data before distributing the map data over the vehicle network to the ECU that applies the map data. In particular, map data needs to be associated with road segments (stretches) to be transferable using the horizon protocol. As mentioned above, map change data may be associated with point, line, and / or area map features. Therefore, it is necessary to identify which of these point, line, and / or area map features in the map change data are associated with a particular road segment (i.e., a specified portion of the road system). Roads within the map area feature changes in the map change data subsequently inherit reality change information from the map area feature associated with the road. This processing occurs prior to in-vehicle distribution using the applied horizon protocol. In other words, changes (e.g., a map area feature shifted in a certain direction relative to satellite positioning due to an earthquake) are processed first (e.g., in map feature adjustment module 190). When there is a request from the ECU for an HD map feature, the map feature data (i.e., HD map data) is obtained (in HD map client 160) and passed along with map change data to map feature adjustment module 190. Map feature adjustment module 190 uses the map change data for the earthquake map area feature to find modifications (changes) that need to be made to the HD map data before sending updated HD map data to the ECU (see below).

[0122] In particular, applying map change data to the stored HD map data when it is stored in the persistent map data cache memory 164 destroys the independence of the two data streams. Therefore, it is desirable that the original (i.e., raw / unprocessed) HD map data (and HD map metadata) be stored in the persistent data cache memory 164. Alternatively (where the specified portion of the road system is the entire road system), the entire HD map data and change map data can be processed to obtain updated HD map data for the entire road system. This updated HD map data needs to be stored separately from the original HD map data from which the requested map features are obtained. This variation is suboptimal, as it doubles the amount of storage required in the persistent map data cache memory 164, even if only a few changes are represented in the map change data. Therefore, it is desirable that the specified portion of the road system be a relatively small portion of the entire road system (e.g., the vicinity of the vehicle), and that updated HD map data be generated on demand for the various ECUs.

[0123] The method 800 includes a third step S806 of generating (e.g., by the map feature adjustment module 190) updated HD map data for the specified portion of the road system based on the map change data related to the updated map features to enable use of the updated HD map data by the automated driving system.

[0124] The method 800 may further include distributing at least a portion of the updated HD map data to at least one electronic control unit in the vehicle.

[0125] With respect to the embodiment of API server 500 described above with respect to FIG. 5 , method 800 may further include sending a request for map change data to a server (e.g., API server 500 of a server system), with the map change data being received from the server in response to the request. The request may be a request for map change data covering the same geographic area as the HD map data stored on the client computer system. Alternatively, the request may be a request for map change data covering a sub-area of ​​the geographic area covered by the HD map data stored on the client computer system. The request may indicate the sub-area by one of (a) explicitly indicating the sub-area, (b) indicating the vehicle's proximity, and (c) indicating the vehicle's current location and vehicle movement history, so that the server can determine the appropriate sub-area. In a further alternative, the request may be a request for map change data regarding a particular map feature of the plurality of map features.

[0126] While it is possible to request map change data for a sub-area, such a model cannot be applied with respect to actual HD map data (including map feature data) because map features may contain links to other map features in the HD map data. Therefore, it is necessary to have the entire dataset of HD map data to ensure that linked data exists. In contrast, map change data does not contain links between map feature changes and therefore it is possible to operate with only a portion of the map change data. This makes it feasible to implement an API model in relation to map change data. Thus, map change data can be obtained for a specified map area, then processed and used for stream editing of the original HD map data.

[0127] As mentioned above, it is possible to combine the map change data and updated metadata aspects of the present application. In this regard, the client computer system may be further configured to receive and store HD map metadata. The metadata includes a confidence level of the HD map data for the plurality of map features. In this case, method 800 may further include receiving updated metadata for one or more map features of the plurality of map features of the HD map data, the updated metadata being received independently of receiving the HD map data. The updated map features are further identified by processing the updated metadata to identify some of the one or more map features associated with the specified portion of the road system. Generating the updated HD map data is further based on the updated metadata for the updated map features.

[0128] Thus, method 800 can use map change data well before an HD map update is received. In other words, the time between a reality change and the vehicle receiving the associated reality change information is typically shorter according to method 800. Thus, an autonomous vehicle can recognize reality changes immediately after they are detected and act on them appropriately, for example, by disabling automated features or by adopting a conservative driving course of action.

[0129] Similar to the method 800 described above with reference to Figure 8, the present application also contemplates a client computer system configured to perform the method (see, e.g., Figures 1 and 4a-4b), as well as a corresponding computer program and a computer-readable medium storing the computer program.

[0130] Client handling of updated metadata The client side of the system has already been described to some extent with reference to client computer system 150 of FIG. 1 . As mentioned above, map interface adapter 165 is configured to provide various data to map feature adjustment module 190. With respect to client processing of updated metadata, map interface adapter 165 may provide HD map data (received from map data service 126 and stored in persistent map data cache memory 164), HD map metadata (received from map metadata service 128 and stored in persistent map data cache memory 164), updated metadata (received from map quality metadata service 314 and stored in persistent map data cache memory 164), and any associated actual changes (i.e., map change data received from map change service 148 and stored in persistent map data cache memory 164). Map feature adjustment module 190 is configured to process the received data to identify map features in the updated metadata that are associated with the specified portion of the road system. Corresponding map features in the map change data may also be identified. The map feature adjustment module 190 generates updated HD map data for the specified portion of the road system. The updated HD map data includes relevant portions of the HD map data updated according to the updated metadata (and associated map change data). The map feature adjustment module 190 is configured to provide the updated HD map data to the HD map application 180 as a map client service. The updated HD map data is configured to be used by the ADS of an autonomous vehicle associated with the client side of the architecture 100. The ADS is embodied by modules such as the controller 166, the ECU platform 170, and the HD map application 180, which are not explicitly shown in FIG. 1 . Additionally, see the description of FIGS. 4a and 4b in the previous section.

[0131] As shown in FIG. 9 , updated HD map data may be generated according to a computer-implemented method 900 on a client computer system (e.g., client computer system 150). The client computer system comprises an automated driving system. The client computer system is configured to receive and store HD map data representing a road system having a plurality of objects (see, e.g., HD map data made available via map data service 126). The HD map data includes a plurality of map features representing the plurality of objects in the road system. The client computer system is further configured to receive and store HD map metadata. The metadata includes a confidence level of the HD map data for the plurality of map features. The HD map data and metadata are suitable for use by the automated driving system.

[0132] The method 900 includes a first step S902 of receiving (e.g., by the HTTPS client 161) updated metadata for one or more map features of the plurality of map features of the HD map data. The updated metadata is received independently of receiving the HD map data.

[0133] The method 900 includes a second step S904 of processing the updated metadata (e.g., by the map feature adjustment module 190) to identify updated map features that are some of the one or more map features associated with the specified portion of the road system.

[0134] In particular, this processing step may occur well after the updated metadata is received (e.g., in a "push" delivery model of updated metadata). Alternatively, if the updated metadata is received in response to a request from a client computer system (i.e., in a "pull" delivery model), the processing step is likely to follow directly from receipt of the requested updated metadata.

[0135] The specified portion of the road system may be a portion of the road system near the vehicle, and the vehicle's proximity may be determined based on the vehicle's current location. The vehicle's proximity may further be determined based on the vehicle's expected direction of travel or travel area. In other words, identifying the portion of the updated metadata related to the vehicle's proximity enables the horizon protocol (e.g., (ADASIS V2, V3)) to properly process the data before distributing the map data over the vehicle network to the ECU that applies the map data. In particular, the map data needs to be associated with stretches of road so that it can be transferred using the horizon protocol. As mentioned above, the updated metadata may be associated with point, line, and / or area map features. Therefore, it is necessary to identify which of these point, line, and / or area map features in the updated metadata are associated with a particular road segment (i.e., a specified portion of the road system). Roads within a map area feature in the updated metadata will inherit the updated metadata from the map area feature that is later associated with the road. This processing occurs prior to in-vehicle distribution using the applied horizon protocol.

[0136] In particular, applying the updated metadata to the stored HD map metadata when stored in the persistent map data cache memory 164 destroys the independence of the two data streams. Therefore, it is desirable to store the original (i.e., raw / unprocessed) HD map metadata in the persistent data cache memory 164. Alternatively (where the specified portion of the road system is the entire road system), the entire HD map metadata and the updated metadata can be processed to obtain updated HD map data for the entire road system. This updated HD map data needs to be stored separately from the original HD map data and HD map metadata. This variation is suboptimal because it doubles the amount of storage required in the persistent map data cache memory 164 for the metadata, even if only a few changes are represented in the updated metadata. Therefore, it is desirable that the specified portion of the road system be a relatively small portion of the entire road system (e.g., the vicinity of the vehicle), and that the updated HD map data be generated on demand for the various ECUs.

[0137] The method 900 includes a third step S906 of generating (e.g., by the map feature adjustment module 190) updated HD map data for the specified portion of the road system based on the updated metadata for the updated map features to enable use of the updated HD map data by the automated driving system.

[0138] The method 900 may further include distributing at least a portion of the updated HD map data to at least one electronic control unit in the vehicle.

[0139] Thus, the client computer system has a module (e.g., map feature adjustment module 190) that first processes the HD map quality metadata (i.e., the updated metadata) and then uses it to insert updated quality attributes into HD map features requested by the HD map application (180) in the vehicle.

[0140] With respect to the embodiment of API server 500 described above with respect to FIG. 5 , method 900 may further include sending a request for updated metadata to a server (e.g., API server 500 of a server system), with the updated metadata being received from the server in response to the request. The request may be a request for updated metadata covering the same geographic area as the HD map data stored on the client computer system. Alternatively, the request may be a request for updated metadata covering a sub-area of ​​the geographic area covered by the HD map data stored on the client computer system. The request may indicate the sub-area by one of (a) explicitly indicating the sub-area, (b) indicating the vehicle's proximity, and (c) indicating the vehicle's current location and vehicle movement history, so that the server can determine the appropriate sub-area. In a further alternative, the request may be a request for updated metadata for a particular map feature of the plurality of map features.

[0141] While it is possible to request updated metadata for a subarea, such a model cannot be applied with respect to actual HD map data (including map feature data) because map features may contain links to other map features in the HD map data. Therefore, it is necessary to have the entire dataset of HD map data to ensure that linked data is present. In contrast, because the updated metadata does not contain links between metadata features, it is possible to operate with only a portion of the updated metadata. This makes it feasible to implement an API model in relation to updated metadata. Thus, updated metadata can be obtained for a specified map area, then processed and used for stream editing of the original HD map metadata.

[0142] As mentioned above, the map change data and updated metadata aspects of the present application may be combined. In this regard, the method 900 may further include receiving map change data describing changes to one or more map features of the plurality of map features of the HD map data, the map change data being received independently of receiving the HD map data. The updated map features are further identified by processing the map change data to identify some of the one or more map features associated with the identified portion of the road system. Generating the updated HD map data is further based on the map change data regarding the updated map features.

[0143] As mentioned in the "Generating Updated Metadata" section, the metadata can include observation date, confirmation date, and confirmation confidence fields. These fields enable the autonomous vehicle's ADS to apply change statistics to continuously correct the map quality indicator for continuously changing differences between the current time and the time of the observations underlying the HD map. This allows the ADS to use HD map data and metadata that provide a more accurate representation of current reality. Thus, when combining SDOs and map data, the ADS has more up-to-date metadata to use when weighting the relative inputs from these two key data sources. The updated metadata is used by the ADS to determine confidence indicators for static geospatial object representations in the environment model. Thus, the autonomous vehicle can recognize the updated metadata immediately after the relevant observations are made (e.g., the autonomous vehicle can be provided with confirmation to avoid increasing uncertainty over time, even in the absence of a new map update) and can act on them appropriately, for example, by disabling / enabling automated features or by adopting a more or less conservative driving behavior course.

[0144] Similar to the method 900 described above with reference to Figure 9, the present application also contemplates a client computer system configured to perform the method (see, e.g., Figures 1 and 4a-4b), as well as a corresponding computer program and a computer-readable medium storing the computer program.

[0145] Fixes It will be understood that the methods described are presented as individual steps performed in a particular order, however, one of ordinary skill in the art will recognize that these steps may be combined or performed in a different order while still achieving the desired results.

[0146] It will be understood that embodiments of the present invention may be implemented using a variety of different information processing systems. In particular, while the figures and their description provide exemplary computing systems and methods, they are presented merely to provide a useful reference in describing various aspects of the present invention. Embodiments of the present invention may be implemented on any suitable data processing device, such as a personal computer, laptop, personal digital assistant, mobile phone, set-top box, television, server computer, etc. Of course, the description of the system and method is simplified for purposes of discussion and is merely one of many different types of systems and methods that may be used for embodiments of the present invention. It will be understood that boundaries between logical blocks are merely illustrative, and that alternative embodiments may merge logical blocks or elements or impose alternative decompositions of functionality on the various logical blocks or elements.

[0147] It will be understood that the functions described above may be implemented as one or more corresponding modules in hardware and / or software. For example, the functions described above may be implemented as one or more software components for execution by a processor of a system. Alternatively, the functions described above may be implemented as hardware, such as on one or more field programmable gate arrays (FPGAs), and / or one or more application specific integrated circuits (ASICs), and / or one or more digital signal processors (DSPs), and / or one or more graphical processing units (GPUs), and / or other hardware arrangements. The method steps performed in the flowcharts contained herein or described above may each be performed by a corresponding respective module, and multiple method steps performed in the flowcharts contained herein or described above may be performed together by a single module.

[0148] To the extent that embodiments of the present invention are implemented by a computer program, it will be understood that one or more storage media and / or one or more transmission media storing or carrying the computer program form aspects of the present invention. A computer program may have one or more program instructions or program code that, when executed by one or more processors (or one or more computers), implements embodiments of the present invention. As used herein, the term "program" may refer to a sequence of instructions designed to execute on a computer system and may include subroutines, functions, procedures, modules, object methods, object implementations, executable applications, applets, servlets, source code, object code, byte code, shared libraries, dynamic link libraries, and / or other sequences of instructions designed to execute on a computer system. A storage medium may be a magnetic disk (such as a hard disk drive or floppy disk), an optical disk (such as a CD-ROM, DVD-ROM, or Blu-ray disk), or memory (such as ROM, RAM, EEPROM, EPROM, flash memory, or portable / removable memory device), etc. A transmission medium may be a communications signal, a data broadcast, a communications link between two or more computers, etc.

[0149] While preferred embodiments of the present invention have been described, it should be understood that these are by way of example only and that various modifications are possible.

Claims

1. 1. A computer-implemented method at a client computer system in an autonomous vehicle, the client computer system comprising an automated driving system, the client computer system configured to receive and store HD map data representing a road system having a plurality of objects, the HD map data including a plurality of map features representing the plurality of objects of the road system, the HD map data for use by the automated driving system, the method comprising: receiving map change data describing a change to one or more map features of the plurality of map features of the HD map data, the map change data being received independently of receiving the HD map data; and storing the received map change data; upon receiving a request from an electronic control unit in the autonomous vehicle for a specified portion of the road system, the specified portion being a relatively small portion of the overall road system that includes at least one map feature in the HD map data, using the map change data to identify updated map features, the updated map features being some of the one or more map features associated with the specified portion; generating updated HD map data for the specified portion of the road system based on the map change data regarding the updated map features; and delivering the updated HD map data for the designated portion to the electronic control unit for use by the automated driving system; and A method comprising:

2. 2. The method of claim 1, wherein the designated portion of the road system is a portion of the road system in a vicinity of the autonomous vehicle, the vicinity of the autonomous vehicle being determined based on a current location of the autonomous vehicle.

3. The method of claim 2 , wherein the vicinity of the autonomous vehicle is further determined based on a direction or area of ​​predicted travel of the autonomous vehicle.

4. 4. The method of claim 1, further comprising sending a request for map change data to a server, said map change data being received from said server in response to said request.

5. 5. The method of claim 4, wherein the request is for map change data covering the same geographic area as the HD map data stored on the client computer system.

6. The client computer system is further configured to receive and store HD map metadata, the HD map metadata including confidence levels in the HD map data for the plurality of map features, and the method further comprises: receiving updated HD map metadata for one or more of the plurality of map features of the HD map data, the updated HD map metadata being received independently of receiving the HD map data; the updated map features are further identified by identifying some of the one or more map features associated with the specified portion of the road system; The method of claim 1 , wherein generating the updated HD map data is further based on the updated HD map metadata regarding the updated map features.

7. 7. A method according to any preceding claim, wherein the map change data is configured to indicate one or more changes to be applied to the one or more map features to provide one or more updated map features.

8. 8. The method of claim 1, wherein the HD map data covers a specified geographic area and includes multiple layers, each layer including a different type of map data for the specified geographic area, and the map change data covers the same specified geographic area.

9. A client computer system configured to perform the method of any one of claims 1 to 8.

10. A computer program product which, when executed by one or more processors, causes said one or more processors to perform a method according to any one of claims 1 to 8.

11. A computer readable medium storing a computer program according to claim 10.

Images