Digital MAP data with improved functional safety

Abstract

To provide a technique for generating a safe and reliable digital map and for provisioning.SOLUTION: The present technique allows verification of digital map data in a map client by using a simple and efficient data structure to check the correctness of map data before distributing a structural element depending on the map data into a vehicle.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention generally relates to methods and systems for providing digital map data, e.g., transmitted from a cloud server environment, to map-based applications running onboard a vehicle. Embodiments relate to methods and systems for providing such digital map data with improved functional safety. In particular, embodiments of the present invention relate to techniques for verifying the integrity (and authenticity) of high-definition (HD) map data before it is provided for use in, e.g., advanced / autonomous driving applications. Embodiments also relate to methods for operating client applications for such contexts. [Background technology]

[0002] Navigation systems use digital maps to assist drivers in reaching a desired destination. Such digital maps typically consist of a collection of navigable segments (i.e., "arcs") and nodes connecting road segments to each other, forming an appropriate graph representation of a navigable (e.g., road) network. Digital map elements have associated navigation cost parameters that can be used in determining the cost of a path to a destination, e.g., for route planning purposes. Digital maps that support basic road-level navigation and route planning services (only) are sometimes referred to as standard-defined maps (SD maps).

[0003] To provide more advanced automated driving (AD) and advanced driver assistance systems (ADAS) capabilities, it is necessary to use so-called high-definition maps (HD maps), which provide highly detailed and precise 3D views of both road and lane geometry. Thus, in addition to the arcs and nodes that define the road geometry, such HD maps also include lane models that describe lane markings, lane centerlines, road boundaries, and so on. A typical HD map thus comprises a set of arcs representing connected areas and lane groups, and a set of nodes that describe the connections between the arcs. Connected areas and lane groups describe the road surface from side to side (as well as along the direction of travel). HD maps effectively extend a vehicle's field of view beyond the range of its local sensors, thereby enabling smoother, safer, and more efficient driving scenarios.

[0004] It will be appreciated that AD / ADAS applications may provide highly automated driving functionality, the safety of which is critically dependent on receiving accurate and up-to-date HD map data that reflects the area of ​​the navigable (e.g., road) network that the vehicle is traveling in. Thus, if the integrity or authenticity of such data used by the AD / ADAS application to navigate the vehicle around the navigable (e.g., road) network is compromised, this could have serious (even fatal) consequences.

[0005] Therefore, digital map data is "safety-critical," and its reliability must be guaranteed to meet the regulatory standards required for in-vehicle systems. For example, it must be guaranteed that the data is not corrupted, for example, during storage and / or transmission. Furthermore, data security is a prerequisite for safety, and it must be guaranteed that AD / ADAS applications are protected from security threats. Therefore, these aspects must be taken into account when achieving functional safety for AD / ADAS applications.

[0006] Functional safety of in-vehicle safety-critical systems is generally achieved by developing systems that comply with the ISO 26262 functional safety standard. The production of safety-critical map data follows the ISO 21448 standard for safety of intended function (SoTIF). Ensuring the reliability of such digital map data therefore imposes certain requirements on the development of map data distribution and delivery systems. However, due to the number of interfaces and functional components associated with a map distribution system, i.e., a map client (interface), it is understood that such a map client (interface) is a functionally complex software component. Therefore, implementing a map data distribution and delivery system with a required functional safety level can be labor-intensive and complex. Therefore, meeting the desired functional safety requirements for AD / ADAS applications typically involves a significant burden for the design, testing, and support of the map distribution and delivery system, and such complex implementations typically require increased processing and storage resources.

[0007] Digital map data for AD / ADAS applications is typically generated remotely, for example in a cloud server environment, by compiling appropriate source data from one or more map data sources, and then the map data is distributed from the cloud to vehicles requiring the map data. An in-vehicle distribution network then distributes the map data as needed to the AD applications requiring the map data (and / or to other map-based applications running on-board the vehicle).

[0008] To provide more efficient distribution of map data, it is known to represent a digital map as multiple map tiles, with each map tile representing a portion of the overall map area and including data indicating objects that fall within the area covered by the map tile. For example, a collection of map tiles may be provided, with different map tiles in the collection representing navigable networks (e.g., roads) in different portions of a geographic area as multiple arcs connected by nodes. Thus, at least object data related to the collection of arcs and nodes that define the navigable (e.g., road) network in that area may be stored for the map tile. This may include object data that defines characteristics of the arcs / nodes themselves (e.g., defining the road / lane geometry in that area) and data on objects associated with the arcs / nodes, such as traffic signs. Of course, any other suitable information that may desirably be included in a map may also be stored for the tile. When a map-based application requires information about a feature or location within the navigable (e.g., road) network, a request may be issued for the associated map tile to obtain the appropriate map (i.e., object) data.

[0009] Such requests are typically processed by a suitable client application (interface) running on the vehicle. The client application (interface) receives the map tiles and then processes them appropriately to extract relevant map data. The client application (interface) can then distribute the map data to any desired application, e.g., an AD / ADAS application, as desired. This is typically done with reference to an appropriate "horizon" generated by considering a predicted approaching driving path, e.g., based on the current vehicle position, driving conditions, and road data. The horizon then relates to a collection of map tiles representing sub-maps within the area leading up to the horizon, to which dynamic (e.g., sensor) data can be added, e.g., to implement AD / ADAS functions. Typically, multiple horizons are generated for corresponding multiple predicted driving paths to better account for and adjust for vehicle deviations from any one of the predicted driving paths.

[0010] The sub-map data associated with the horizon can be provided to the AD / ADAS application, for example, according to the Advanced Driver Assistance Systems Interface Specification (ADASIS) protocol. For example, the new ADASIS V3 standard is often used for in-vehicle HD map distribution. ADASIS V3 consists of a horizon provider, a horizon reconstructor, and the ADASIS V3 protocol used between the provider and the reconstructor. The ADASIS V3 protocol typically uses an in-vehicle network, such as Ethernet. Once the sub-map data is provided to the AD / ADAS application, the application can plan a predictive driving strategy in the usual way, for example, by comparing the in-horizon map data with dynamic sensor data.

[0011] Such systems thus enable map data to be delivered directly to vehicles. However, when map data is provided as a collection of tiles, it can still be difficult to ensure the functional safety of the map data being used by AD / ADAS applications. Furthermore, existing approaches to achieving functional safety can be relatively complex to implement, and it would be desirable to provide more efficient client applications (interfaces) that can achieve the required functional safety.

[0012] Therefore, the applicant believes that there remains room for improved ways of providing map data while still meeting desired functional safety requirements, for example, for AD / ADAS applications. Summary of the Invention

[0013] According to a first aspect of the present invention, there is provided a method of validating map data being transmitted from a remote server to one or more map-based applications executing on an electronic control unit (ECU) of a vehicle traveling through a navigable network covered by a digital map, the digital map being represented as a collection of a plurality of map tiles, each tile representing a particular geographic area including a portion of the navigable network, the method comprising: generating, at a server, a data structure for map tiles, the data structure including object data indicative of a set of one or more objects that fall at least partially within the geographic area covered by the tile and / or within the geographic area covered by one or more other of the tiles representing the digital map; for at least one object in a set of one or more objects for which object data is included in the map tile data structure, associated security data is included in the map tile data structure along with the object data for the at least one object, the security data being usable to verify the integrity of the associated object data; and transmitting the map tile data structure for the tile, including the object data and associated security data, from the server to a client application executing on one or more processing units of the vehicle.

[0014] The present invention generally relates to the generation and provision of digital map data, and more particularly to the provision of high-definition (HD) digital map data suitable for advanced and / or automated driving applications. It will be appreciated that, particularly for automated driving (AD) applications, map data is safety-critical and, therefore, its authenticity must be guaranteed to meet the safety requirements of in-vehicle safety-critical systems. Accordingly, embodiments of the present invention relate to methods for validating such digital map data before distribution and use by, for example, map-based applications running onboard a vehicle. Furthermore, developing a map client interface that can meet desired safety requirements can be challenging and intensive. Accordingly, embodiments of the present invention also relate to the efficient implementation of map client applications with enhanced levels of functional safety (e.g., ASIL-8), as further described below.

[0015] For example, in an embodiment of the first aspect of the present invention, a method is provided for validating digital map data at the "object level", which allows individual map objects to be validated in an efficient manner without significant additional storage and / or transmission overhead, even when the map data is packaged into multiple map tile data structures for transmission purposes, as described further below.

[0016] It will be appreciated that such digital maps are typically complex data structures containing roads, road lanes, connections, traffic information, points of interest, and many other types of information. Accordingly, to reduce the amount of data that must be stored locally in a vehicle running a map-based application and / or to reduce the bandwidth required to transmit map data to the vehicle, the overall area represented by the digital map may be (and is) divided into multiple smaller area regions for data storage purposes, and the device need only retrieve data relating to the region associated with its current location and / or projected driving path. In the present invention, the smaller area regions into which the overall area is divided for mapping purposes are referred to as "tiles." However, other equivalent terms may be used, and it will be appreciated that the term "tile" does not imply any particular limitation on the shape or size of the regions into which the digital map is divided.

[0017] The use of such a tile-based approach may help provide more efficient transmission and distribution of map data from various map data sources to vehicles requiring the map data. For example, an advantage of a tile-based approach is that map data from different sources can be easily compiled into a collection of individual tiles at a server (or multiple servers), and then the associated map data can be distributed or provided, e.g., tile-by-tile, to vehicles requiring map data for the areas covered by the tiles. The tile data structure can then be unpacked, e.g., by a suitable client application (interface) running on one or more processors onboard the vehicle, to extract the desired (map) object data, which may be distributed as needed to various map-based applications running within the in-vehicle environment.

[0018] Part of ensuring the trustworthiness of map data and enhancing functional safety for applications that rely on map data is being able to verify the integrity and authenticity of the data being delivered to vehicles. To this end, tile data structures may (and in preferred embodiments are) digitally signed so that tile data structures received by a client application (interface) can be checked to match those sent from the original server. Thus, in embodiments, after the tile data structures are compiled on a first server, each tile data structure may be digitally signed by that (or another) server before being delivered to the vehicle. For example, this may involve adding a digital signature, such as a 256-byte SHA-2 digital signature or similar, to each tile data structure. This approach allows for verification of data integrity and authenticity at the tile level, i.e., the level at which the data is retrieved from the server. Thus, when a tile data structure is sent from a server to an appropriate client application (interface) running on a vehicle, the client application (interface) can check the digital signature to verify the integrity of the tile data structure before the client application (interface) attempts to use or distribute the map object data stored for the tile. Of course, this tile-level verification need not use digital signatures, and any other suitable verification technique could be used as needed.

[0019] This tile-level validation is important, for example, to ensure that the tile data structure has not been altered or corrupted during transmission. However, it will be appreciated that any end application requiring map data (which may be an AD application or an Advanced Driver Assistance Systems (ADAS) application running on the vehicle's ECU, but may also include any other navigation or geospatial awareness application running within the in-vehicle environment) typically does not use map data at the tile level, but instead requires access to object data that can be extracted from such tile data structures. Thus, a client application (interface) operates in conjunction with or as part of an in-vehicle map distribution network to extract relevant object data from the tile data structure at a level that can be used by the map-based application and provide such data to the map-based application. For example, the client application (interface) may provide map (object) data directly to a map-based (e.g., AD / ADAS) application. Alternatively, the client application (interface) may provide the map (object) data to, for example, a horizon provider, which then passes the map data to the map-based application. Of course, other configurations are possible.

[0020] Thus, it will be appreciated that being able to verify the authenticity / integrity of data at the tile level does not, in itself, ensure that the map (object) data ultimately provided to and potentially used by a map-based application, e.g., for autonomously driving a vehicle, is trustworthy, and therefore additional safety measures may be required to ensure that relevant functional safety standards for the application are met. For example, while validating a tile data structure may allow the authenticity of the object data contained within the tile data structure to be verified (i.e., by confirming that the data originates from a trusted source, e.g., a verified server), it is recognized that the object data itself may still be modified during transmission and / or in storage, and therefore the integrity of the object data should desirably be verified before it is provided to the map-based application, e.g., in case the data is somehow corrupted or modified within the in-vehicle map distribution network, and / or while it is held locally, e.g., in a cache associated with the client application (interface). Furthermore, it is desirable that this data can be verified while limiting the software / hardware complexity of the client application (interface) and the amount of additional data that needs to be distributed within the vehicle.

[0021] Accordingly, embodiments of the present invention propose that security data be provided at the object level for at least some of the objects in a particular tile data structure (preferably in addition to the tile-level verification described above). That is, in preferred embodiments, in addition to providing authentication and / or integrity verification at the tile level, i.e., at the level at which data is accessed from the server by a client application (interface), the present invention also provides security data at the level of meaningful entities ultimately used by map-based applications, i.e., the objects whose data are stored in the tile data structure. The associated security data for the objects can be used (e.g., by a client application) to verify the integrity of the object data itself. Thus, the tile data structure includes associated security data for verifying the integrity of the object data for at least some of the objects in which the object data is stored. In this way, object data for objects of interest can be easily verified both before its in-vehicle delivery and before its use by any in-vehicle application, ensuring that relevant functional safety standards can be met.

[0022] In particular, this means that when storing or accessing object data from a local data store accessible by, for example, a client application (interface), it can be guaranteed that the object data has not been corrupted or damaged after it has been received. Furthermore, in preferred embodiments, this is done with relatively little additional processing overhead, and without requiring, for example, that the entire map data distribution system have to be developed to the required level of security, as described further below.

[0023] The invention also extends to a map distribution (or production) system for carrying out such a method. Thus, according to a second aspect, there is provided a map distribution system comprising at least one remote server in communication with client applications (interfaces) running on one or more processing units of vehicles traveling within a navigable (e.g. road) network covered by a digital map, the digital map being represented as a collection of a plurality of tiles, each tile representing a particular geographical area comprising a portion of the navigable (e.g. road) network, the at least one remote server generating a data structure for map tiles, the data structure representing one or more tiles that fall at least partially within the geographical area covered by said tile and / or within the geographical area covered by another one or more of said tiles representing said digital map. and transmitting the map tile data structure for the tile containing the object data and associated security data from the server to a client application executing on one or more processing units of the vehicle.

[0024] This second aspect of the invention may, and preferably does, include any one or more or all of the preferred and optional features of the invention described herein with respect to the first aspect in any of its embodiments, as appropriate. For example, even if not explicitly stated, a system may, and in an embodiment does, include means for performing any one or more of the steps described in connection with the methods herein in any of its aspects or embodiments, and vice versa.

[0025] In an embodiment, a digital map includes multiple levels (or layers), with each level divided into multiple tiles in the manner described above. That is, the tiles are arranged into multiple distinct levels, and thus each map tile may contain object information for its associated level of the map. For example, different levels of a map may be used to store different types of object data. Thus, each map level may contain a subset of the available map information. For example, the base level of a map may contain basic road geometry information (e.g., a collection of arcs and nodes that define a navigable (e.g., road) network). Then, different types of objects and / or attributes may be stored at progressively higher levels within the map. This structure advantageously allows a map-based application that does not require the map data to extract map data from any of the levels, allowing the map-based application to extract (only) the relevant information depending on what information is needed by the application.

[0026] The tiles (or more specifically, levels within a map) representing a map may generally take any suitable form, as desired. The tiles may have either regular or irregular shapes. For example, in some cases, the tiles may follow the boundaries of a region (e.g., a country, state, province) and therefore may have irregular shapes and sizes. In other cases, more typically, the tiles into which an entire area is subdivided comprise an array of regularly shaped tessellated units. Typically, the tiles may be rectangular (e.g., square), although other shapes may be suitably used, including pentagons, triangles, etc., and combinations thereof. All of the tiles for a map may have the same size. However, embodiments also contemplate that tiles may have variable sizes. This may be the case either for tiles within a single level of the map, or for tiles across different levels. For example, in the latter case, different levels may be used to store map data at different levels of granularity, rather than (or in addition to) storing different types of data at different levels of the map. In particular, providing variable tile sizes, whether within a single level of a map or across multiple map levels, may enable data-dependent sizing of tiles, e.g., the physical size of a tile is selected so that each tile data structure has approximately the same data size. This may help facilitate more efficient transmission of map data and more effective use of available tiling resources (and associated data allowance for tiles), especially when the density of map data varies significantly. Thus, for relatively sparse (e.g., rural) areas where there is relatively little map content of interest, the area may be represented using relatively large tiles. Meanwhile, relatively smaller tiles may be used to represent more densely populated (e.g., urban) areas where the amount of map content that needs to be stored is likely to be greater.

[0027] Thus, each tile represents and is associated with a particular geospatial area within the overall area covered by the map. An appropriate data structure may then be generated for each tile, describing any objects that are within the tile's associated area and that should be included in the map. The objects whose data are stored for the tile may include any suitable objects that may desirably be included in a map. Thus, the objects may represent real-world objects such as road elements, junctions, points of interest, traffic signs, traffic lights, speed cameras, etc. However, digital map data also includes other types of information objects that may be used to encode map information. For example, objects may be used to identify locations where speed limits change or to provide virtual nodes between road elements. The objects whose data are stored for a particular tile may include any such objects. It will be understood that the data stored in the tile data structure is not limited to data representing "objects" but may include any other suitable data, such as data that may desirably be included in a map. For example, in an embodiment, the tile data structure also includes data representing any attributes associated with a navigable (e.g., road) network, such as speed limits. Any such attribute data may also be stored with appropriate security data in a manner similar to that described herein for object data.

[0028] It will be appreciated that the core information of an HD map, for which reliability must be guaranteed, is the collection of arcs and nodes that represent connected areas and lane groups associated with a navigable (e.g., road) network. Thus, the object for which object data is stored for a tile typically includes at least object data for the collection of arcs and nodes that represent the road network within the area of ​​the map covered by the tile. Thus, any reference to an object or object data herein may be understood to refer, in embodiments, to (at least) arc and / or node data, or object data associated with the arcs / nodes.

[0029] While dividing a digital map into smaller area tiles in the manner described above can be useful for reducing storage requirements, it will be appreciated that this approach results in tile boundaries that need to be resolved. For example, because people / vehicles can typically travel from one tile to an adjacent tile, there will be map objects (roads, junctions, points of interest, etc.) that span tile boundaries. That is, at least some of the map objects may (and at least some typically do) contain elements that extend across multiple tiles. In such cases, to avoid having to split the object data, the object data may (and in some preferred embodiments is) replicated and stored separately in each of the tiles across which the elements extend. This can be beneficial because it avoids the need to attempt to "stitch" objects that appear in different tiles across tile boundaries. In this case, security data is stored along with the object data for each of the associated tiles. However, of course, other approaches for storing such data are possible. For example, in another preferred embodiment, object data for a particular object may be stored in a single tile data structure (only), even if the object represents an element that extends across multiple tiles, resulting in the object data being stored (directly) in a single tile (only). For any other tiles within which the object is at least partially located, appropriate references or pointers are generated and stored to point to tile data structures containing the associated object data. Thus, in some embodiments, if an object extends across multiple adjacent tiles at a particular level of a map, the object data may be stored in a first tile (only), with other tiles within which the object falls referencing the first tile. Similar referencing may also be performed between tiles at different levels, e.g., object data appearing in a first-level tile is stored for a second-level tile such that the first-level tile contains appropriate references to the second-level tile.

[0030] It will thus be appreciated that the data indicative of an object stored in a particular tile data structure may be the object data itself (i.e., data that directly indicates the object), or may be data that only indirectly indicates the object, for example, in the form of an appropriate pointer to another tile data structure in which the object data is stored. Thus, a tile data structure may correspondingly contain data not only about objects that fall within the area covered by its respective tile, but also about objects that fall at least partially within the area of ​​another of the tiles (which may, for example, be an adjacent tile on the same map level as the tile in which the data is stored, or a tile on another level). In this case, security data about the object may also be stored only in the data structure of the first tile, i.e., the tile in which the object data is stored.

[0031] However, in principle, various other configurations for storing data indicative of objects for a tile are possible. Indeed, in general, data indicative of objects for a particular tile may be stored in any suitable manner. For example, data may represent objects in any manner; this does not imply any particular form of relationship between the data and the objects, so long as some suitable association exists that allows the relevant object information to be properly extracted and used. Object data may be stored directly or indirectly in a data structure for the tile. Furthermore, data may be stored in either compressed or uncompressed (raw) format, as desired.

[0032] The security data associated with an object may take any suitable form, as appropriate. Various techniques for verifying data integrity and / or authenticity are well established and may be used as needed. In particularly preferred embodiments, the security data comprises a 64-bit truncated SHA-256 hash value (or hash code). This has been found to provide a suitable tradeoff between reliability and the implications of storage space and cellular network usage. Security hashes may be easily implemented at the desired functional safety level. For example, the security data may be provided in the form of a digital signature. However, checking a digital signature is more complex than (re)calculating a hash value and therefore more difficult to implement, especially if the system is to be designed according to a higher functional safety level (e.g., ISO 26262:2018 ASIL-BASIL-B level or higher). Thus, in some embodiments, for at least some of the objects in the tile data structure in which security data is stored (and preferably for each object), the security data may be provided in the form of a security hash of the object data calculated at the server. Thus, the object data may be verified at the client application (interface) by the client application (interface) recalculating a hash value based on (at least) the object data and comparing it with the hash value contained in the security data. In a preferred embodiment, map tile metadata is also transferred separately from the map data. The metadata may include, for example, version and format information about the tile and / or map. In this case, the hash associated with the object data for the object is preferably calculated based on the object data, and the metadata about the tile within the object data is also stored. The metadata is preferably also protected by the hash. That is, map tiles preferably have associated metadata that has its own hash.

[0033] However, it will be appreciated that other configurations for authenticating object data and metadata are possible and the use of a security hash is not required. For example, it will be appreciated that in other embodiments the security data may alternatively or additionally comprise any suitable error detection code (e.g., minimum distance code, hash code, check sum code, parity code, cyclic redundancy check, etc.), error correction code (e.g., block code, convolutional code, Hamming code, Viterbi code, etc.), message authentication code, digital signature, etc. Furthermore, any combination of these techniques may be applied in an embodiment.

[0034] As alluded to above, security data may be stored for each object for which object data is stored for a particular tile. Security data may also be stored for each object individually, i.e., in a one-to-one correspondence. Alternatively, security data may be associated with and stored for object data for one or more, e.g., a collection of objects, e.g., a collection of objects that may typically be accessed together. However, security data need not be stored for each object data included in a tile data structure; in some embodiments, security data is stored for fewer than all of the objects in a particular tile data structure. For example, security data may be stored only for certain, e.g., safety-critical, objects. This may involve storing security data only for objects at the base level of a digital map. Alternatively, different types of security data may be stored for different types of objects, e.g., at different levels of a map, to provide different levels of verification.

[0035] It will be appreciated that road geometry elements such as arcs (lane groups, connected areas) and nodes are essential elements of HD maps and core safety-critical entities for HD map applications. Therefore, security data should (and is) stored for at least these objects. Thus, in an embodiment, a map tile may represent a navigable network in a portion of a geographic area as a plurality of arcs connected by nodes, with each arc and node in the tile having object data and security data (e.g., a hash value) associated with it. For example, in a particularly preferred embodiment, a hash value (or hash code) is calculated at the server for each arc (e.g., lane group or connected area) and node for which data is stored, and the hash value is then added to the tile data structure along with the object data describing the arc / node. The hash value preferably covers not only the object data but also any associated metadata about the tile in which the object is stored. Thus, each arc and node at which object data for a tile is stored has an associated hash value that is based (calculated) not only on the object data but also on the associated tile metadata for the tile that contains the object data. When a data structure containing the object data and hash value for an arc / node is unpacked at a client application (interface), the hash value for the arc / node may then be recalculated by the client application (interface) based on the received object data (and preferably on any associated metadata, which is also transmitted separately), and the recalculated hash value is then compared with the original hash value calculated at the server to verify the integrity of the object data. In an embodiment, tile metadata, which is transmitted separately from the map data, is also protected by a hash.Thus, a client application (interface) may perform similar operations and comparisons on the tile metadata to check the integrity of the metadata before using it to check the integrity of the object data in the tile. Thus, the method generally includes a client application unpacking a tile data structure to extract object data indicating one or more objects whose data are stored in the tile data structure, and the client application using associated security data to verify the integrity of the extracted object data.

[0036] However, various other configurations are of course possible, depending for example on the type of security data to be provided.

[0037] For other less important objects, security data may not need to be stored. Nevertheless, in preferred embodiments, security data is also stored for other objects in the map. For example, in preferred embodiments, higher level objects in the map, which may be speed limits, driving restrictions, etc. associated with particular arcs and nodes, get associated hashes that cover the associated object data and an index reference to the arc or node with which the object data is associated. Note that lane groups and connecting areas may also include "keys or index references" to their two associated nodes. The integrity of any sub-map can then be guaranteed because they are covered by the hashes of the lane groups and connecting areas.

[0038] If the object data is properly verified, e.g., using its associated security data, e.g., in the manner described above, it may be properly distributed to any map-based application requiring the map data for use. On the other hand, if the object data cannot be verified because it fails a security check, an appropriate integrity error signal may be generated. Alternatively, or additionally, if the verification fails, the client application (interface) may make another attempt to obtain the object data. For example, multiple attempts may be made until a timeout criterion is met (e.g., a certain period of time has elapsed or a certain number of attempts have been made), at which point an appropriate integrity error signal may be generated. The integrity error signal is then preferably communicated to the map-based application, which may act accordingly. For example, if the map-based application is an automated driving application (or if the map-based application is a vehicle horizon provider that then provides map data to the automated driving application), the automated driving application may operate the vehicle in a safe mode and / or bring the vehicle to a safe stop when an integrity error message is generated.

[0039] Tile data structures for tiles representing a digital map are generated in a central server and then transmitted from the server as needed to any vehicle traveling within the navigable (e.g., road) network and communicating with the server. Client applications (interfaces) running on the vehicles may communicate with the server using any suitable wireless communication protocol. In some embodiments, communication is performed using the HTTPS protocol (over TLS). All messages sent between the TLS server and TLS client are encrypted and remain private even if intercepted. TLS provides message integrity by computing message digests. Certificate chain-based certificate validation allows the TLS client (i.e., the part of the client application (interface) that communicates with the server) to authenticate the data provided by the TLS server (i.e., map tile data and map tile metadata). However, other configurations are of course possible.

[0040] It will be understood that, as used herein, a "server" may generally refer to a collection or cluster of one or more servers. In particular, it will be understood that a server need not be a (single) physical data server, but may comprise, for example, a virtual server running a cloud computing environment. Thus, a server may be a cloud server. It will also be understood, therefore, that a vehicle may receive map data from multiple servers, from which it may obtain map data for, for example, corresponding multiple map data sources. Thus, any reference to a server in this document should be understood to mean "at least one server," unless the context requires otherwise. Of course, various other configurations are possible.

[0041] Thus, the server may generally include a tile generator with access to a database of digital map data and tile parameters that indicate how the digital map data should be sorted into tiles. The tile generator may be implemented by a digital map compiler. A digital map compiler compiles map information retrieved from a database in one format into another format, such as one that conforms to a standardized map specification (e.g., NDS, OSM), or generates map information for a specific application (e.g., car navigation, on-foot navigation, vehicle-type-specific navigation, public transit navigation, ADAS systems, autonomous vehicle control, etc.). For example, the map compiler may be provided by a back-office application that may use proprietary information to compile the map information. The map compiler retrieves digital map data as presented in one form of presentation, such as in a digital map database, and generates tiles. Each tile contains digital map data related to a given area covered by the digital map. That is, a digital map is typically generated by a server retrieving a collection of map source data, sorting the map source data into individual levels and / or tiles of the digital map, and then compiling the tile data structure accordingly. The data included in the map may be obtained from several different sources. It will be understood that the map data may be added to the tile data structure in any suitable format. For example, object data may be stored directly or indirectly in the data structure for the tile. Furthermore, the data may be stored in either compressed or uncompressed (raw) format, as desired. Preferably, the data is compressed to facilitate transmission.

[0042] Once the map tile data structure for a particular tile has been compiled, the generated tile data structure may then be stored in an appropriate map tile data store (e.g., a database) at the server along with individual tile data structures for other tiles representing the digital map. Thus, while embodiments are described with reference to generating a tile data structure for a single tile, it will be understood that a tile data structure is generated for each and every tile representing the map in the same manner as presented above. The tile data structure for the map tile (or at least its latest version) is then stored in an appropriate map tile data store on the server. Thus, the server comprises a map tile data store. Thus, in embodiments, the method includes storing the tile data structures in a map tile data store on the server, from which they may then be retrieved for transmission from the server to any vehicle requiring the map data stored in the tile data structures. The server also comprises a metadata store for storing associated metadata to be transmitted to the vehicle along with the tile data structures. The tile data structure is available for transmission from the map tile data store to a vehicle, for example, in response to a request for information about a feature or area defined in the digital map, as described further below. The tile data structure is also updated over time. Thus, a particular collection of map tiles may collectively form a digital map having a particular "map version." Each map tile in a map has its own associated "tile version." It will be understood that a tile version may be associated with multiple map versions. The tile version and map version information are preferably stored and transmitted via metadata associated with the tile data structure. Thus, there may be multiple metadata records for each map tile.The specified map version should generally be the latest map version available on the server (if connectivity is available to make a latest version call to the server via the first and second applications), or the latest map version used (if connectivity is not available).

[0043] The tile rendering application can then retrieve tile data structures from the map tile data store as needed for transmission to vehicles requesting map data from the server, e.g., based on the vehicle's current location or other points of interest. Thus, tile data structures may be selectively transmitted (e.g., distributed) from the map tile data store to a client application (interface) running on the vehicle, and the associated map data may ultimately be distributed to the map-based application requiring the map data. For example, a map-based application may generate a request for data regarding a particular real-world feature or geospatial area or location within a navigable (e.g., road) network. It will be understood that the map-based application does not use data at the tile level. Thus, the feature request must be translated into an appropriate request for object data (e.g., for arcs or nodes) that can be created at the tile level. In an embodiment, a client application (interface) running on a computing device associated with the vehicle serves to process such requests to obtain the required map data. For example, a client application (interface) may unpack a tile data structure to extract data representing one or more objects, and then use the associated security data to verify the integrity of the extracted object data. The client application (interface) may, for example, execute at least in part on one or more electronic control units (ECUs) of a vehicle.

[0044] In a preferred embodiment, the client application is split into a first application (client front-end) and a second application (client back-end) that communicate with each other. This may provide a particularly efficient implementation for achieving a desired level of functional safety, as described further below.

[0045] In particular, the client application may comprise a first application that communicates with one or more map-based applications running onboard the vehicle, and a second application that communicates with the server and the first application. The first application preferably runs on the same ECU as the map-based applications. The second application may also be on the same ECU. In this case, the first and second applications may interact via remote procedure calls using inter-process communication provided by the underlying ECU platform. This allows relying on secure inter-process communication provided by the ECU platform operating system, i.e., a secure communication protocol stack for inter-processor communication may be avoided. However, this need not be the case; the second application may be provided on a separate ECU platform from the first application. Similarly, the first application may be provided to the map-based applications on a separate platform. It will be appreciated that there may typically be multiple map-based applications running onboard the vehicle, each of which may be served by the same client front-end (or, alternatively, by multiple separate client front-ends).

[0046] The first application (client front-end) is responsible for processing requests from the map-based application and translating these requests into object requests, i.e., requests for object data related to a particular (real-world) feature about which the map-based application is requesting information. Thus, the first application may receive a request from the map-based application for map data related to a particular feature of a navigable (e.g., road) network. The first application then processes this request to determine the object associated with that feature, as defined within one of the tiles representing the map. The first application then requests object data and security data for the area / object of interest from a second application. The object data and its associated security data are then retrieved by the second application and provided to the first application. The first application may then perform any desired validation of the object data, i.e., object-level validation, using the associated security data (e.g., hash value) for the object that is also provided within the tile data structure. If the validation is successful, the first application can then provide the object data to the map-based application. If the validation fails, an integrity error message may be generated, which may prompt further requests, etc. Similarly, if the requested map data is not returned within a certain period of time, a timeout error message may be generated and communicated to the map-based application.

[0047] Thus, the second application (client backend) serves as an interface between the server and the first application (client frontend). Thus, the second application is operable to issue requests for digital map data to at least one server. To reduce the latency associated with such requests, at least some object data and security data received from the server may, and preferably is, stored locally, e.g., in a suitable cache accessible by the second application. Thus, when such data is requested by the first application from the second application, the second application may first attempt to retrieve the data from the associated cache. If the data is not available in the cache (there is a cache miss), the data is then retrieved from the server. On the other hand, if the data is already available in the cache (a cache hit), it may then be immediately provided to the first application for validation, etc. The object data and security data may be periodically evicted from the cache, e.g., based on an appropriate cache management policy. Thus, the second application preferably comprises one or more caches for locally storing tile data structures and tile metadata. For example, the second application may comprise a map tile cache that stores multiple tile data structures retrieved from a remote server. The second application is also preferably a map tile metadata cache that stores associated metadata for each of the tile data structures retrieved from the remote server. The second application can then retrieve any map data requested by the first application from the cache (if the data is available in the cache) or from the server, as needed. The second application (client backend) also preferably performs any desired validation / authentication of tile data structures as they are received from the server and added to the cache.For example, if the tile data structure is digitally signed, the second application (client backend) preferably checks the digital signature to validate the tile data structure, i.e., tile-level validation is delegated to the second application (client backend) and object-level validation is delegated to the first application (client frontend).

[0048] Thus, in an embodiment, the method includes receiving, by a first application, a request from a map-based application for digital map data related to a feature of a navigable network, requesting, by the first application, object data and security data (e.g., hash values) for at least one arc or node associated with the requested digital map data from a second application, and retrieving, by the second application, the requested object data and security data (e.g., hash values) from a map tile cache, or from a map tile data store if the requested tile is not stored in the map tile cache, and providing them to the first application. Associated tile metadata may also be transmitted, for example, as described above. Thus, the method may further include the first application requesting, from the second application, metadata about map tiles related to at least one arc or node associated with the requested digital map data, and the second application retrieving, by the second application, the requested tile metadata from a map tile metadata cache or, if the requested tile metadata is not stored in the map tile metadata cache, from a map tile metadata data store, and providing it to the first application. The first application can then verify the integrity of the data using associated security data (e.g., a hash) before providing the data to the map-based application. Thus, the method may include the first application calculating, by the first application, a new hash value for the at least one arc or node, comparing, by the first application, the new hash value with the received hash value, and sending, by the first application, the requested digital map data or an integrity error message to the map-based application.In a preferred embodiment, the security data includes (at least) a hash value determined based on the object data and associated tile metadata for the tile in which the object data is stored, such that calculation of a new hash value may be performed using the object data and the associated tile metadata.

[0049] Thus, the client application (interface) translates a request for information from the map-based application, which may be a request for information about any particular feature or area within the digital map, into a request for object data associated with such feature, so that the relevant object data can be fetched from its associated tile data structure. The advantage of dividing the client application into a first application (client front-end) and a second application (client back-end) as described above is that functional safety requirements can be fully delegated to the first application (client front-end). For example, it is the first application that preferably performs any desired validation of the object data before ultimately distributing it to the map-based application that generated the request. Thus, the first application (client front-end) should be developed to meet the strict functional safety procedures required to ensure the authenticity of such data. However, this does not mean that the second application (client back-end) is required to meet such strict safety procedures.

[0050] For example, the ISO 26262 functional safety standard for road vehicles defines four Automotive Safety Integrity Levels (ASILs): ASIL-A, ASIL-BASIL-B, ASIL-C, and ASIL-D. ASIL-D dictates the highest level of safety integrity (ASIL A dictates the lowest). An additional class, QM (Quality Management), is used to indicate cases where no safety requirement is mandated. Developing high-ASIL products is complex, labor-intensive, and costly due to the heavy demands placed on the development process. However, the ISO 26262 standard defines an ASIL decomposition method that allows a high ASIL requirement to be decomposed into two or more requirements of the same or lower ASIL. By applying this method, the parts of a system that need to be implemented at a high ASIL can be limited, for example, to the first application (client front-end).

[0051] For example, it is typically desirable to develop an in-car HD map distribution system to at least ASIL-BASIL-B. By dividing the client application as described above, the first application (client front-end) can be developed to the ASIL-BASIL-B standard (or higher, if necessary). This implementation may involve using any appropriate countermeasures to address random and / or systematic failures. For example, random failures may cause changes in the code, stored data, or I / O data of a running software application. On the other hand, systematic failures may occur due to errors in the requirements, design, or implementation of a software application. Reducing random failures may be achieved, for example, by adding runtime testing, fault detection, fault monitoring, redundant execution, and redundant and diverse implementations. For example, increasing the number of (separately developed) implementations of a module within a software application reduces the module's vulnerability to random failures because it is highly unlikely that a random failure will cause the same effect in both implementations. This can be detected in the software application. Such diverse software modules also reduce systematic failures because different implementations are less likely to have the same software bug. Any of these techniques may be used to design the first application (client) with a desired level of functional safety. For example, in embodiments, the client application may be implemented with at least partial redundancy.

[0052] However, the second application (client backend) interacting with the server does not need to meet such requirements. Thus, in a particularly preferred embodiment, the first application is developed at the ASIL-BASIL-B level (or higher), while the second application is preferably developed at a lower level of functional safety. This also helps simplify the overall map distribution system, since the interface with the server (i.e., the second application (client backend)) does not need to be developed at the same level as the client frontend, e.g., the ASIL-B level. This can be much more efficient than trying to implement the entire system, including the interface with the external server, at the required, e.g., ASIL-B functional safety level. Thus, in fact, according to a preferred embodiment, the retrieval and authentication of map tiles can (and does) occur independently of the verification of object data within the map tiles. This allows functional safety requirements to be met without significantly increasing the system's complexity.

[0053] For example, as described above, tile-level authentication / verification is preferably performed by the second application (client back-end), preferably at the server, using digital signatures applied to the tile data structures. It will be appreciated that digital signatures can be easily implemented, for example, to ASIL-QM standards, but may be more difficult to implement at higher safety levels, such as ASIL-B. On the other hand, object-level verification is performed by the first application (client front-end), to ASIL-B standards (or higher). For example, object-level verification, as described above, is preferably performed using hash values, for example, which can be easily implemented at the desired safety level.

[0054] Thus, after the second application (client backend) verifies the authenticity / integrity of the tile data structure, the first application (client frontend) can then perform further validation to verify the integrity of the object data received from the second application (client backend) before finally passing the object data to, for example, a map-based application. In this way, client applications (interfaces) can be implemented with the desired functional safety level in an efficient manner.

[0055] If the validation fails, this may then be signaled to the map-based application as an integrity error. The first application (client front-end) may attempt to retry fetching the data. If the object data is safety-critical and validation fails, the map-based application may then enter a "safe mode," for example, by disabling the automated driving system or safely stopping the vehicle. It will be appreciated that the map-based application may be any application that may request map data. Preferably, this is an AD or ADAS application, as these are the contexts in which map data is safety-critical and therefore must be validated. Similarly, the map-based application may include a vehicle horizon provider that in turn provides map data to the automated driving application. Thus, in embodiments, the map-based application is the automated driving application, or the map-based application is a vehicle horizon provider that in turn provides map data to the automated driving application. However, in principle, it may also be used to deliver map data to any other navigation or geospatial awareness application running within the vehicle's environment.

[0056] From another aspect, a method for operating a client application executed onboard a vehicle traveling over a navigable network within a geographic area covered by a digital map, the digital map being represented as a collection of a plurality of map tiles, each tile representing a particular geographic area including a portion of the navigable network, the method comprising: object data indicative of a set of one or more objects that fall at least partially within the geographic area covered by the map tiles and / or within the geographic area covered by one or more other of the map tiles representing the digital map; and an associated map tile data structure including security data for verifying the integrity of object data associated with at least one object whose object data is stored in the map tile data structure; The method comprises: receiving, at the client application, a request from one or more map-based applications for map data regarding one or more features of the navigable network; retrieving, by the client application, object data associated with the feature from a respective map tile data structure; retrieving associated security data for the retrieved object data from the individual map tile data structure; the client application uses the security data to verify the integrity of the object data, and if the data is verified, passes the object data to the map-based application. From a further aspect, a client application is provided for running onboard a vehicle moving within a navigable (e.g., road) network covered by a digital map, the digital map being represented as a collection of a plurality of map tiles, each tile representing a particular geographic area including a portion of the navigable network, each map tile comprising object data indicative of a collection of one or more objects that fall at least partially within the geographic area covered by the map tile and / or within the geographic area covered by one or more other of the map tiles representing the digital map, and wherein the object data is stored within the map tile data structure, the object data being indicative of a collection of one or more objects associated with at least one of the objects. a client application configured to receive requests from one or more map-based applications for map data related to one or more features of the navigable network, retrieve associated security data for the retrieved object data from the respective map tile data structures, use the security data to verify the integrity of the object data, and pass the object data to the map-based application if the data is verified.

[0057] According to a further preferred aspect, there is provided a method of operating a client application executing on one or more central processing units of a vehicle navigating a navigable network within a geographic area to provide digital map data from at least one remote server to a map-based application executing on an electronic control unit (ECU) of the vehicle, the client application including a first application and a second application, the first application in communication with the map-based application and the second application, the second application in communication with the at least one remote server, the at least one remote server including: (i) a map tile data store storing a plurality of map tiles, each map tile representing the navigable network within a portion of the geographic area as a plurality of arcs connected by nodes; and (ii) a map tile metadata store that stores metadata for each of the map tiles in the map tile data store, each arc and node of a tile having object data and an associated hash value, the hash value being calculated based at least on the object data for the individual arc or node and tile metadata for the tile that includes the object data for the individual arc or node; the second application includes (i) a map tile cache that stores a plurality of map tiles retrieved from the at least one remote server; and (ii) a map tile metadata cache that stores the metadata for each of the map tiles in the map tile cache retrieved from the at least one remote server; receiving, by the first application, a request from the map-based application for digital map data relating to characteristics of the navigable network; requesting, by the first application, from the second application, the object data and hash value for the at least one arc or node related to the requested digital map data; obtaining, by the second application, the requested object data and hash value from the map tile cache, or from the map tile data store if the requested tile is not stored in the map tile cache, and providing them to the first application; requesting, by the first application, from the second application, the metadata for the map tile relating to the at least one arc or node relating to the requested digital map data; obtaining, by the second application, the requested tile metadata from the map tile metadata cache, or from the map tile metadata store if the requested tile metadata is not stored in the map tile metadata cache, and providing it to the first application; calculating, by the first application, a new hash value for the at least one arc or node based on the received object data and tile metadata; comparing, by the first application, the new hash value with the received hash value; and providing, by the first application, either the requested digital map data or an integrity error message to the map-based application based on the comparison.

[0058] The above-described method of operating the client application (interface) can be advantageous in itself for meeting functional safety requirements, regardless of whether object-level verification is used. For example, delegating functional safety to the front end allows for separation of this from map tile access, which can simplify access requirements and help avoid the need to build an entire map distribution system, including the server interface, at a high (e.g., ASIL-B) level. Instead, ASIL-B requirements are met by decomposing the client application into a relatively secure front end and a less secure back end. Thus, the present invention also extends to a vehicle distribution system based on the above principles. In this case, the first application (client front end) should preferably run on the same ECU as the map-based application (although this is not required), and the map data returned to the map-based application is extracted from object data retrieved from the associated map tiles.

[0059] Thus, from another aspect, there is provided a method of operating a client application executing on one or more central processing units (CSUs) of a vehicle navigating a navigable network within a geographic area to provide digital map data from at least one remote server to a map-based application executing on an Electronic Control Unit (ECU) of the vehicle, the client application including a first application and a second application executed on the ECU, the first application communicating with the map-based application and the second application, the second application communicating with the at least one remote server, the at least one remote server accessing a map tile data store that stores a plurality of map tiles, each map tile representing the navigable network within a portion of the geographic area as a plurality of arcs connected by nodes, each arc and node of a tile having object data associated therewith, the second application including a map tile cache that stores the plurality of map tiles retrieved from the at least one remote server, the method comprising: receiving, by the first application, a request from the map-based application for digital map data relating to characteristics of the navigable network; requesting, by the first application, from the second application, the object data for the at least one arc or node associated with the requested digital map data; retrieving, by the second application, the requested object data from the map tile cache, or from the map tile data store if the requested tile is not present in the map tile cache, and providing them to the first application; identifying, by the first application, the portion of the object data that corresponds to the characteristic of the navigable network; and providing, by the first application, the requested digital map data to the map-based application using the identified portion of the object data.

[0060] It will be appreciated that any of the further aspects of the invention may include any or all of the features of the invention described in relation to any other aspect and embodiment of the invention, to the extent that they are not mutually inconsistent. In particular, it will be appreciated that the invention in its second and further aspects may include any or all of the features described in relation to the method of the first aspect of the invention, and vice versa.

[0061] The present invention also extends to a map data distribution and delivery system for performing the methods described above in connection with any of the aspects and embodiments of the present invention. For example, the map data distribution / delivery system may include a server in communication with one or more vehicles, the server including suitable map generation circuitry (including a map tile compiler, etc.), one or more data stores for storing map tile data and metadata, and transmission circuitry for transmitting map tile data structures to the vehicles. The vehicles include one or more processors that execute various client applications that process the map tile data structures, as well as one or more map-based applications that execute on the vehicle's engine control unit (ECU) that request the map data. Such a system may be configured to perform any (or all) of the method steps described herein. For example, the system may include a collection of one or more processors operable or configured to perform the above-described steps. Any step may be performed by any one of the processors or by multiple processors.

[0062] The various functions of the techniques described herein may be performed in any desired and suitable manner. For example, the steps and functions of the techniques described herein are implemented in hardware or software, as appropriate. Thus, for example, unless otherwise indicated, the various processors, functional elements, stages, and "means" of the techniques described herein may include any suitable one or more processors, one or more controllers, functional units, circuits, processing logic, microprocessor configurations, etc. operable to perform the various steps or functions, etc., such as suitable dedicated and / or programmable hardware elements (processing circuits) that can be programmed to operate in a desired manner. For example, the means for performing any of the steps of a method according to any of the aspects or embodiments described herein may generally comprise a collection of one or more processors (or processing circuits) configured to do so, e.g., programmed with a set of computer-readable instructions. A given step may be performed using the same or different set of processors as any other step. Any given step may be performed using a combination of sets of processors. The system may further comprise data storage means, such as a computer memory, for storing at least one repository containing instructional and informational data, for example. Any of the methods according to the present invention may be implemented, at least in part, using software, e.g., a computer program. Accordingly, the present invention also extends to a computer program product comprising computer-readable instructions executable to perform, or to cause a system and / or server to perform, a method according to any of the aspects or embodiments of the present invention. Accordingly, the present invention also extends to a computer program product, preferably non-transitory, comprising computer-readable instructions executable when executed on a system according to any of the embodiments of the present invention to cause a set of one or more processors of the system to perform the steps of any of the method aspects or embodiments described herein.

[0063] Note that references herein to objects, features, areas, etc. associated with a tile or tile data structure should be understood to refer to data representing them, unless the context requires otherwise. The data may be in any manner that represents the associated item, and may represent it directly or indirectly. Thus, any reference to an object, feature, area, tile, etc. may be replaced by a reference to data representing it. Also, note that the words "associated with" or "representing" should not be construed to require any particular restriction on data storage location; the wording requires only that the features be identifiably associated.

[0064] Various features of embodiments of the invention are described in further detail below. [Brief explanation of the drawings]

[0065] Various embodiments are now described, by way of example only, and with reference to the accompanying drawings. [Figure 1] An overview of the map distribution system is shown below. [Figure 2] , [Figure 3] , [Figure 4] , [Figure 5] , [Figure 6] , [Figure 7] , [Figure 8] 1 shows a schematic diagram of how a digital map may be compiled according to an embodiment, the digital map comprising multiple layers, each represented using multiple tiles; [Figure 9] 1 illustrates a schematic diagram of a cloud-based map distribution system according to an embodiment in which map data is distributed from the cloud to vehicles running one or more map-based applications. [Figure 10] 1 illustrates a schematic representation of a client application for processing map data according to an embodiment; [Figure 11]1 illustrates a schematic representation of a cache that may be used to locally store map data according to an embodiment; [Figure 12] 1 illustrates a cloud-based map data distribution system according to an embodiment. [Figure 13] 1 illustrates another variant of a map data distribution system according to an embodiment. [Figure 14] 10 illustrates another example of a single map front end being served by multiple map clients according to an embodiment.

[0066] Where appropriate, like reference numbers are used for like elements in the drawings. DETAILED DESCRIPTION OF THE INVENTION

[0067] The present invention relates generally to a method for obtaining digital map data for use by geospatially aware map-based applications, particularly Automated Driving (AD) and Advanced Driver Assistance Systems (ADAS) applications where reliability and accuracy of the digital map data are safety critical. Here, an embodiment of an efficient implementation of a map client application running onboard a vehicle having an enhanced (e.g., ASIL-BASIL-B) level of functional safety is described.

[0068] Functional safety is important when automated functions have a potential impact on humans. Such automated functions are typically required to meet specific standardized functional safety levels, either by regulators, clients, or users. Meeting such functional safety requirements throughout the product lifecycle has significant implications for the design, testing, and support of the implementation. The technical impact of implementing an automated function in accordance with functional safety requirements can be substantially larger and more complex. This can be seen, for example, in increased code size and increased data storage required for the functional safety implementation.

[0069] Functional safety deals with ensuring that an implementation operates as expected. This means that the implementation must consider the effects of both random and systematic failures. Random failures result from the effects of material aging due to external factors such as vibration, temperature, humidity, and radiation. Random failures may cause changes in the code, stored data, or 1 / 0 data of a running software application. Systematic failures may occur due to errors in the requirements, design, or implementation of a software application. Functional safety engineering practices aim to reduce systematic failures by employing rigorous development practices intended to substantially reduce the probability of systematic failures. Random failure reduction may be achieved, for example, by adding runtime testing, fault detection, fault monitoring, redundant execution, and redundant polymorphic implementation.

[0070] The increased fault tolerance of an implementation developed using functional safety engineering methodology costs double or triple the cost of the hardware, software, development, testing, and maintenance.

[0071] 1 shows an overview of a map distribution system 10 comprising a map compiler 12 and a tile metadata service 14 deployed on a cloud server system 16, a tile data service 18 deployed on a content delivery network (CDN) 20, and a client application (interface) 22 deployed on a vehicle. The combination of the metadata service 14 and the data service 18 is also referred to as a "cloud service."

[0072] The map compiler 12 receives map data from a suitable cartography unit 24 located on the cloud server system 16. The cartography unit 24 receives map source data from various data sources 26 and then converts it into an appropriate format for inclusion in the digital map. The map compiler 12 then sorts the map data into individual layers and tiles for the digital map, as further described below.

[0073] This allows the map distribution system 10 to use the map client 22 to distribute map data directly from the map production unit 24 in the cloud to the autonomous driving application 11 running on the electronic control unit (ECU) of the vehicle 9.

[0074] Figure 1 illustrates the functional modules of a map client 22 and its interfaces to various functional modules in the map server infrastructure and in the vehicle. For example, the map client 22 of Figure 1 includes six components: a map interface adapter 101, a client library 102, a persistent cache 103, a tile validator 104, an HTTPS client 105, and a controller 106. These functions are described in further detail below with respect to the map client illustrated in Figure 11. However, it can already be seen from Figure 1 that due to the number of interfaces and functional components in the map client, a functional safety implementation of the map client may be complex and require significant resources (e.g., computational power, storage requirements, energy consumption, etc.).

[0075] The map distribution system 10 shown in Figure 1 is generally operable to distribute required digital map data to any map-based application running onboard a vehicle that requires the map data. Digital map data is typically complex.

[0076] For example, it will be understood that a digital map typically includes multiple map objects that represent real-world objects, such as navigable elements of a navigable (road) network, junctions, points of interest, etc. A navigable (e.g., road) network is typically a network comprising multiple interconnected (e.g.,) roads that can be navigated by a vehicle. A navigable (e.g., road) network may typically be represented by a digital, or electronic, map (or mathematical graph). In its simplest form, a digital map is essentially a database containing data representing nodes, most commonly representing road intersections, and arcs between these nodes, representing the roads between these intersections. In more detailed digital maps, arcs may be divided into segments defined by start and end nodes. These nodes may be "real," in that they represent road intersections where at least three lines or segments intersect, or "artificial," in that they serve as anchors for segments not defined at one or both ends by real nodes, to, among other things, provide shape information for a particular stretch of road or to provide a means of identifying locations along the road where some characteristic of that road, e.g., speed limit, changes. In virtually all modern digital maps, the nodes and arcs (or arc segments) are further defined by various attributes that are also represented by data in a database. For example, each node typically has geographic coordinates that define its real-world location, e.g., latitude and longitude. A node also typically has maneuvering data associated with it that indicates whether it is possible to move from one road to another at an intersection. For purposes of conventional navigation guidance, such as may be provided by known portable navigation devices, elements of a digital map need only include information about road centerlines (and typically only that), but each road segment may be supplemented with attributes such as maximum allowed speed, lane size, number of lanes, whether there are dividers between them, etc.However, as described further below, in accordance with embodiments of the present invention, digital maps may be generated (or used) that provide a more accurate and realistic representation of road profiles, including lane centerlines and lane connectivity (i.e., lane markings), as well as other key elements such as the three-dimensional geometry of navigable (e.g., road) networks, such as landmark objects that may desirably be incorporated into the maps. This type of digital map may be referred to as an "HD" map (as compared to conventional "SD" maps, which include road centerlines but not lane centerlines). The additional information included in HD maps, and at least lane markings, is generally required for automated driving (AD) purposes. However, the use of these HD maps is not limited to AD applications; these maps may also find suitable use in any other application in which it is desired to provide an improved and more accurate representation of road profiles, including, but not limited to, various advanced driver assistance systems (ADAS) applications. Digital map data may also be used in numerous other map-aware or geospatial applications not necessarily related to navigation, such as applications requiring location knowledge, e.g., weather applications. Thus, HD maps may also include data representing any other features that may be appropriate and desirable to include in such maps. Although various embodiments are described herein with respect to HD maps, it will be understood that the techniques described herein are also applicable to SD maps.

[0077] Automated vehicles are highly dependent on external data, such as sensor information and HD maps. If the integrity or authenticity of this data is corrupted, the autonomous driving function may use the faulty data to steer the vehicle, resulting in unsafe driving. The safety goal of the vehicle's autonomous driving task is to keep the risk of human physical injury or harm to health below an acceptable level. Therefore, it is desirable to ensure the functional safety of such map data before use.

[0078] In this embodiment, the HD map data includes multiple layers, each of which includes multiple tiles. The tiles are associated with a geospatial rectangular area. The entire map and each individual map tile have a "version," and the map includes a consistent collection of layers and tiles. A tile may be part of several versions of a map; that is, tiles of a particular version may be associated with multiple map versions. Thus, map data may be divided into layers to group data according to data type so that clients can selectively download data relevant to their purposes. This example is shown schematically in FIG. 2, which illustrates a map 30 divided into multiple levels. Specifically, the map includes a base level 50 containing basic road and lane shapes and a series of higher levels that store different types of data associated with the road network. Each layer is represented as multiple tiles. Thus, FIG. 3 illustrates how data is organized within a digital map. Specifically, the digital map 30 is composed of multiple map layers 32, each of which includes multiple map tiles 34. The digital map 30 is associated with a map version 31, and the map tiles 34 are associated with a tile version 35. Thus, the current map version 31 contains the latest set of map tile versions 35. Map and tile version information is preferably transmitted as tile metadata.

[0079] As shown in FIG. 4, this embodiment distinguishes between two types of map layers: object layers and attribute layers. Object layers contain geospatial objects with associated shapes and attributes that do not change frequently. Objects may have associations with other objects, either in the same layer or in other layers. Attribute layers contain attributes associated with geospatial objects residing in other layers. Attributes residing in the attribute layer are typically expected to change more frequently than their associated objects. For example, in this embodiment, the map includes a base layer called the HD Roads layer. The HD Roads layer is a directed graph containing arcs and nodes. Each arc has two associated nodes: one node for connection with an incoming arc and one node for connection with an outgoing arc. There are two types of HD Map arcs: lane groups and connected areas. A lane group consists of one or more lanes with shapes and attributes. A connected area contains a shape, legal trajectory, and attributes. A high-level organization of the data structure for the roads layer 50 is shown in FIG. 5.

[0080] The road layer 50, in turn, consists of multiple HD road tiles. That is, the HD road layer is divided into multiple road tiles, and each road tile contains arc and node data for the area of ​​the map represented by the tile. The data structure for tiles 60 in the road layer is shown in Figure 6. In particular, for each road arc 61 and node 62 within the area of ​​the map covered by the tile, security data in the form of an appropriate hash is stored alongside the associated arc / node data. In other words, object-level verification is provided.

[0081] FIG. 7 shows in more detail an example of a tile data structure 700 that may be generated and transmitted in this embodiment. The tile data structure 700 includes a tile header 701, tile data 702, and a tile signature 703. When the tile data structure 700 is transmitted to a client application, the tile header 701 can be read in the usual way to identify the tile in question. For example, the tile header 701 may include information such as a tile ID, a layer ID, a layer format, a tile version, etc., and the tile data 702 can then be appropriately extracted. In this embodiment, the tile data structure 700 is digitally signed with the tile signature 703, which allows the authenticity of the tile data structure 700 to be verified.

[0082] The tile data 702 includes a list of HD road objects (e.g., HD road arcs or HD road nodes) 704. An HD road object includes a map object id and map object data. The HD road object id field establishes a unique reference for the HD road object. In some variations, the HD road object id may be associated with the location origin of the HD road object relative to the map area covered by the tile. The HD road object data includes a field to determine the type of HD road object (e.g., arc data or node data) and a data field to describe the arc or node.

[0083] For each road object 704, a collection of associated functional safety data, or security data 705, is also included in the tile data structure 700. In the example shown in Figure 7, the tile data 702 includes an ordered list of object data 704 and associated security data 705. However, this need not necessarily be the case, and of course the data may be arranged in any suitable manner.

[0084] In this embodiment, the security data 705 is a hash value that extends to the map object ID and the map object data. This embodiment uses a secure hash function because it is relatively immune to any cause or pattern of failure of the protected data. However, the functional safety data is not affected by any Error-detecting code (minimum distance code, hash code, checksum code, parity code, cyclic redundancy check code) or any Error Correction Code (Block code, convolutional code, Hamming code, Viterbi code).

[0085] Additionally, the HD map may include other layers, such as an HD speed limit layer, an HD traffic sign layer, etc. The HD speed limit layer consists of a collection of speed limits associated with lane stretches. Speed ​​limits in the speed limit layer are associated with lanes and lane groups in the HD road layer. Similarly, the HD traffic sign layer consists of a collection of traffic signs with shapes and attributes. Traffic signs may be associated with objects in the HD road layer. However, other arrangements of layers are of course possible, and in general, the HD map may include additional or fewer layers as needed.

[0086] According to the present invention, lane groups, connecting areas, and nodes (i.e., connections) are preferably stored in a single tile, even if they actually cross the tile's geospatial boundaries. In addition to the benefit of avoiding cutting and stitching (which can result in loss of data quality), as explained further below, tiles remain highly independent, and the integrity of these significant entities can be provisioned in the data structure of the tile to which they belong. In an embodiment, this is done by duplicating object data for both (or all) tiles across which the associated object extends and storing the object data for both tiles separately. However, it is also possible to store the object data in only one of the tiles, with the other tile containing an appropriate reference (e.g., pointer) to the tile in which the data is stored. This approach is illustrated in FIG. 8, where a road element 80 extending from a first tile 81 to a second tile 82 is stored only in the first tile 81. An appropriate bounding box 83 representing the location of the road element 80 is then stored in the second tile 82, along with an appropriate reference (pointer) to the first tile 81 that points to the element's associated object data.

[0087] 9 illustrates an example of a mapping system according to an embodiment. As shown, map source data is obtained from multiple sources 26, and then the map source data is sorted into individual levels and tiles within levels by a suitable map compiler 12. The map tiles can then be appropriately distributed by a tile data service 18 to vehicles requiring the map data.

[0088] FIG. 10 illustrates a schematic diagram of a cloud-based map distribution system according to an embodiment in which map data is distributed from the cloud to vehicles running one or more map-based applications. The system of FIG. 10 comprises map production in the cloud, map tile distribution from the cloud to vehicles, and in-vehicle map distribution to map applications, similar to that described above in connection with FIG. 1. However, in FIG. 10, the map tile compiler 12 now includes a map functional safety circuit 1210 that operates to add object security data to the map tile data structure, i.e., in the manner shown in FIG. 7 above. The HD functional safety module 1210 extends the tiled map compiler with functionality to protect the integrity of map objects contained in map tiles. Naturally, there are a wide range of possible implementations for generating security data and associating it with object data.

[0089] 10, client application interface 22 is decomposed into a relatively small client front-end 92 (first application) and a larger client back-end 91 (second application). The client back-end implements functional and safety requirements at QM(B), while the client front-end implements safety requirements at ASIL-BASIL-B(B). The present invention considers client front-end 92 to be small and simple due to its created ability to verify the integrity of HD map data at the level of entities that are meaningful to HD map applications, i.e., lane groups, connected areas, and their associated entities, currently only attributes such as speed limits.

[0090] The client front-end 92 is shown in more detail in FIG. 11 and comprises four components: a client interface adapter 301, an HD map RPC client stub 302, an HD map data validator 303, and a controller 304. The client front-end is a software library developed in compliance with the required procedures of ISO 26262 ASIL-BASIL-B. The library links to other software and executable portions deployed on a process provided by an ASIL-B compliant ECU platform operating system 105. The client front-end is initialized, controlled, and monitored through an interface provided by its controller component 304. The controller 304 interacts with other client front-end embedded components, but the interfaces for these interactions are not shown in FIG. 11.

[0091] The Client Interface Adapter 301 provides a client front-end service interface to the HD Map Application 11. Service requests received from the HD Map Application 11 are passed to the Client Backend via the HD Map RPC Client Stub 302. The HD Map data returned by the Client Backend 91 is validated by the HD Map Data Validator 303 before responding to the associated service request.

[0092] The HD Map Validator 303 is an essential part to achieve the required functional safety. All object level safety mechanisms are based on hashing. A SHA-256 hash truncated to 64 bits is used. This is because 64 bits is an acceptably small size, while 2 -64 (=5.42×10 -20) translates into a failure rate for the same low security mechanism. The client front end 92 checks the integrity and validation of the object data. The client front end 92 may also check the integrity of the latest map version or perform any other desired security checks.

[0093] The client backend 91, also shown in FIG. 11, comprises six components: HD Map RPC Service Stub 201, Client Library 202, Persistent Cache 203, Tile Validator 204, HTTPS Client 205, and Controller 206. The client backend 91 is a software library developed using standard Quality Management (QM) procedures. The library links to other software and executable pieces deployed on a process provided by the ASIL-B compliant ECU platform operating system 105. The client backend is initialized, controlled, and monitored through interfaces provided by its controller component 206. The controller interacts with other client backend embedded components, but the interfaces for these interactions are not shown in FIG. 11.

[0094] Service requests received from the client front-end 92 are passed to the client library 202. The client library services these requests, which may require retrieving tile data and tile metadata from a persistent tile cache 203 or from cloud services, i.e., the tile data service 18 and the tile metadata service 14. Before using the tile data and tile metadata received from the cloud services, their integrity and authenticity are verified by the tile verifier 204. For example, each map tile may have a digital signature (applied by at least one remote server). The signature is verified by the client back-end before the data is provided to the client front-end. It will be appreciated that checking a digital signature is more complex than hashing and is difficult to implement at ASIL-B. However, this can easily be done at the QM level within the client back-end 91.

[0095] In case of validation issues, an error is reported to the Tile Data Service and, if applicable, to the client front-end 92 via the response of the initiating service request. The HD Map RPC client stub 102 in the client front-end also includes a timeout mechanism that returns a timeout error if the client back-end 91 does not respond to the API call within a specified timeout (passed as an API call parameter).

[0096] The client library 202 stores tile data and tile metadata in the persistent cache 203 so that they are readily available for later use. Before using data retrieved from the persistent tile cache 203, its integrity is verified by the tile validator 204. If a validation problem occurs, the affected data is purged from the cache and retrieved anew from the cloud service. Figure 12 shows a conceptual structure of the persistent tile cache 203. The persistent tile cache can be considered to consist of two caches: a tile data cache 401 and a tile metadata cache 402. The cache contains a collection of cache records: tile data cache records and tile metadata cache records. Because tiles of a particular tile version can exist in several maps, each with its own unique map version, a tile data cache record has one or more associated tile metadata cache records. The association is represented by the tile ID, layer ID, and tile version they share in common. The tile metadata cache record contains metadata that the cloud service computes over the entire record, excluding the metadata signature. The tile metadata hash is a 64-bit truncated SHA-256 hash used by client front-ends to validate the tile metadata.

[0097] The client library 202 interacts with the cloud services 14, 18 via an HTTPS client 205. The HTTPS client 205 authenticates, for example, the tile data service 18 and the tile metadata service 14e. For example, a client backend 91 may interact with the cloud services via TLS. All messages sent between the TLS server and the TLS client are encrypted and remain private even if intercepted. TLS provides message integrity by computing message digests. Certificate chain-based certificate validation allows the TLS client (i.e., the client backend 91) to authenticate the TLS servers (i.e., the map data server and the map metadata server). To retrieve a tile, the HTTPS client first retrieves the tile metadata from the tile metadata service 14. This metadata includes the URI of the associated tile, which is used to retrieve the tile from the tile data service 18 if the tile is not already present in the persistent tile cache 203.

[0098] Map tiles and map tile metadata are stored in tile data cache records and tile metadata cache records, respectively. The cache records are digitally signed by the cloud service and verified by the tile verifier, which digitally signs all contents of the persistent tile cache. The creation and verification of the digital signature relies on asymmetric cryptography, using a private encryption key in the cloud and an associated public decryption key in the vehicle. After successful verification, both the integrity and authenticity of the tile data and tile metadata are guaranteed.

[0099] The ASIL-B safety mechanisms in the client front-end verify the integrity of the HD map data that the client provides to the HD map application. These safety mechanisms operate at the level of arcs (i.e., lane groups and connected areas), arc-related attributes, and nodes. Because this level is ensured by the client front-end, the client back-end does not need to be developed at the ASIL-B level. Therefore, the client back-end may be developed in compliance with, for example, ISO26262:2018QM.

[0100] Both the client front-end 92 and the back-end 91 may be deployed on the same ECU platform and interact via RPC with the underlying ECU platform-provided IPC. This allows them to rely on the secure IPC provided by the ECU platform OS, i.e., avoiding a secure communication protocol stack for inter-processor communication. For example, both the client front-end and the client back-end may include a C++ library that is linked with other code and resides in an associated executable. These executables are deployed on the same ECU platform and interact via RPC with the underlying ECU platform-provided IPC. In that case, sufficient independence of the QM part (client back-end) and the ASIL-B part (client front-end) may be achieved by deploying them in separate processes provided by the underlying ASIL-B-compliant ECU platform operating system. The RPC-based interaction between the front-end and back-end relies on the secure IPC mechanisms also provided by the ASIL-B-compliant ECU platform. However, this does not necessarily have to be the case; they may reside on different ECU platforms.

[0101] Thus, the present embodiment relates to an implementation of an augmented map client for autonomous vehicle applications with improved fault resilience. In particular, instead of applying resilience techniques to the entire map client implementation, an augmented map client is provided that includes a map client backend 91 and a map client frontend 92, where (only) the map client frontend 92 is designed using functional safety-enhancing techniques. A detailed description of the overall operation of the system according to the present embodiment is now provided. However, other configurations are of course possible.

[0102] As described above, the map client front end 92 interfaces with the map application (or multiple map applications) and the map client back end 91. The HD map application interacts with the map client front end 91 using a fault recovery map client service interface that comprises a map client service interface extended with service interfaces for fault detection, fault reporting, and fault diagnosis.

[0103] Thus, the map client front end 92 provides fault monitoring and reports any detected faults to the HD Map Application using the fault recovery map client service interface. The purpose of the map client front end is to detect map client failures by verifying the integrity of the data it provides. If a fault is detected in the data from the map client, the map client front end discards the faulty data and reports the fault to the HD Map Application.

[0104] In this embodiment, the map client front end 92 uses functional safety data associated with HD road object data generated by the HD map functional safety module 1210 in the map tile compiler 12 of the map server infrastructure. The map tile compiler 12 compiles HD road arcs and HD road nodes (map objects) and then generates "functional safety data" over these compiled data structures (map objects).

[0105] The map client backend 91 receives, validates, and caches tile data with HD road object data. However, it does not modify, generate, extend, or manipulate the HD road object data (arc and node data) or its associated functional safety data. Therefore, the HD road object data and associated functional safety data as output by the map client should be identical to the data generated within the map server infrastructure.

[0106] The map client front end 92 receives the functional safety data with the HD road object data. If the functional safety data does not match the HD road object data, this indicates a failure in the map client providing the data. After detecting a failure in the data received from the map client, the map client front end blocks the data and reports the failure to the HD map application that requested the data. The HD map application may use the failure report to trigger an appropriate response. Thus, the map client front end protects the HD map application from failures in the map client module and from failures in the communication path from the map server to the map client front end.

[0107] The fault detection capabilities of the map client front-end are small compared to the set of functions in the map client back-end, meaning that they are suitable for implementation using functional safety engineering techniques. A functional safety implementation of the map client front-end detects and reports all failures of the map client and, due to its functional safety engineering implementation, is resilient to failures in the map client front-end implementation itself. The combination of the map client and the client front-end is called the augmented map client. The augmented map client according to the present invention consists of a (standard) map client implementation and a functional safety map client front-end implementation. This implementation of the augmented map client provides compliance with functional safety requirements. It achieves this using substantially fewer resources compared to a functional safety implementation of the map client alone.

[0108] The Augmented Map Client provides a functionally safe map client service interface for HD map applications with only a small increase in resources (hardware, software, storage, energy, development, testing, maintenance).

[0109] Another benefit of splitting the map client 22 in the above manner is that the client front end 92 helps protect the map application from implementation enhancements in the client back end 91. Variant map client implementations may improve resilience using normal development practices without affecting the functional safety compliance of the extended map client. Due to the structure of the extended map client, the implementation of the map client front end 92 is independent of the functionality of the map client back end 91. Because functional safety compliance is determined by the map client front end implementation, any changes to the map client do not affect the functional safety compliance of the extended map client.

[0110] The map client front end 92 may also be configured to handle failures within the map client back end 91 that cause it to fail to respond to a request (in a timely manner). For example, the map client back end 91 may associate a threshold response time with each request from the HD map application and return a timeout failure response to the HD map application if the map client does not respond to a request within the threshold response time associated with the request.

[0111] The HTTPS client circuit 205 of the map client backend 91 retrieves the data structure tile. The client library circuit 202 of the map client backend 91 first sends the tile to the tile validation circuit 204 of the map client backend 91. The tile validation circuit 204 verifies the authenticity and integrity of the received tile data structure 700 using the tile signature 703. After tile validation, the client library circuit 202 sends the tile to the persistent tile cache 203 for storing the tile data 702.

[0112] The map interface adapter circuit of the map client backend 91 receives requests for HD road object data from the HD map application. It then forwards these requests to the client library circuit. The requests can be for HD road objects based on a specific HD road object ID or based on a specific location. The result can be that the requested HD road object does not exist, or one or more HD road objects can be returned from the persistent tile cache 204. The result of the request is returned to the HD map application via the map client adapter 201. Note that the entire HD road object (i.e., the tuple: HD road object ID, HD road data, functional safety data) is returned. In this embodiment, the map client frontend 92 forwards requests from the HD map application and checks the returned HD map object to detect failures within the map client backend 91. The map client frontend 92 uses security data 705 to check the HD map object data 704.

[0113] Since the map client backend 91 is not involved in creating or processing the security data 705 in any way, a malfunction of the map client backend 91 can be reliably detected in the map client frontend 92 .

[0114] Thus, the above-described system enables the distribution of map data to vehicles. In particular, the present embodiment ensures secure distribution of HD map data to vehicles by verifying the integrity and authenticity of at least desired HD road-level map data prior to subsequent in-vehicle distribution. (HD map data that is not associated with a navigable (e.g., road) network, e.g., traffic signs, may or may not be verified depending on the desired level of functional safety.) For example, upon accepting a request for HD map data, the client either provides the HD map data specified in the request (i.e., the correct data) or returns an integrity error. Upon accepting a request for HD map data, the client either provides the requested HD map data within a specified timeout or returns a timeout error immediately after the timeout. In particular, upon accepting a request for HD map data, the client backend subsequently provides the client frontend with HD map data equal to the HD map data retrieved from the cloud service (e.g., after checking authentication and data integrity at the tile level), as well as associated hash values ​​of the map data (i.e., arcs and nodes). The client frontend then verifies the integrity of the HD map data provided by the client backend using the associated hash data, and if the HD map data is verified, the client frontend can provide the requested HD map data to the map-based application. If the HD map data cannot be verified, the client frontend may issue another request for the data or may issue an integrity error if the verified HD map data is not provided, for example, within a specified timeout.

[0115] Map metadata is transferred separately from the map data and is also protected by a hash: every lane group and connecting area has associated metadata with its own hash. The metadata includes version and format information.

[0116] Another variant of the map data distribution system is shown in Figure 13. This embodiment utilizes and extends the approach described above for an in-vehicle HD map distribution system. Here, a single client backend 91 serves multiple client frontends 92A, 92B distributed within the vehicle via remote procedure calls (RPCs). In the vehicle, RPCs are typically implemented on top of TCP / IP over Ethernet. Relying on secure in-vehicle network communications, the system delivers end-to-end (from cloud services to in-vehicle HD map applications) of HD map data for consumption by the HD map application.

[0117] Note that this system transmits more data over the in-vehicle network than, for example, ADASIS V3 does. However, ADASIS V3 was inspired by ADASIS V2, which needed to be deployed on a low-bandwidth CAN network. Both ADASIS V2 and V3 allow fine-grained selection of the data transferred. However, Ethernet has a much higher bandwidth than CAN, so optimizing for the minimum amount of data to transfer is less important. The client presented above provides an API for making fine-grained selection after data transfer and validation.

[0118] FIG. 14 shows another example where a single map front end 92 is served by multiple map clients (client back ends 91A, 918).

[0119] Thus, the present embodiment provides an HD map distribution system that is secure and includes verifying the integrity / authenticity of HD map data at the level of significant entities (such as lane groups and connected areas) before being distributed to applications. Furthermore, the desired functional safety is achieved in an efficient manner by dividing the map client into a front / back end that can be implemented with different levels of functional safety.

[0120] The foregoing detailed description has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the technology described herein to the disclosed technology. Many modifications and variations are possible in light of the above teachings. The described embodiments have been chosen to best explain the principles of the technology described herein and its practical application, thereby enabling those skilled in the art to best utilize the technology described herein in various embodiments, and with various modifications appropriate to the particular uses contemplated. Thus, the features disclosed in this specification, drawings, and / or claims may be material for the realization of various embodiments taken alone or in various combinations thereof. Furthermore, while the present invention has been described with reference to various embodiments, it will be understood by those skilled in the art that various changes in form and detail can be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. 1. A method of operating a client application executing on one or more processing units of a vehicle traveling over a navigable network within a geographic area to provide digital map data from at least one remote server to one or more map-based applications executing on an electronic control unit (ECU) of the vehicle, the method comprising: the client applications include a first application and a second application running on the ECU, the first application communicating with the map-based application and the second application, and the second application communicating with the at least one remote server; the at least one remote server has access to a map tile data store that stores a plurality of map tiles, each map tile representing the navigable network within a portion of the geographic area as a plurality of arcs connected by nodes, each arc and node of a tile having object data associated therewith, and each map tile having an associated map tile data structure including object data indicative of a set of one or more objects that fall at least partially within the geographic area covered by the map tile and / or within the geographic area covered by another one or more of the map tiles representing the digital map, and object level security data for verifying the integrity of the object data associated with at least one object for which object data is stored in the map tile data structure; The second application includes a map tile cache that stores a plurality of map tiles retrieved from the at least one remote server, and the method further comprises: receiving, by the first application, a request from the map-based application for digital map data relating to a feature of the navigable network; requesting, by the first application, from the second application, the object data for at least one arc or node related to the requested digital map data; obtaining, by the second application, the requested object data and associated object level security data, wherein the requested object data and associated object level security data are obtained from the map tile cache if the requested object data is present in the map tile cache, or from the map tile data store if the requested tile associated with the requested object data is not present in the map tile cache; providing the requested object data and associated object level security data to the first application; verifying, by the first application, the integrity of the retrieved object data using the associated object level security data; identifying, by the first application, a portion of the object data that corresponds to the characteristic of the navigable network; and providing, by the first application, the requested digital map data to the map-based application using the identified portion of the object data.

2. 10. The method of claim 1, wherein the second application is developed to a lower functional safety standard than the first application.

3. 3. The method of claim 2, wherein the first application is developed in accordance with at least ISO 26262:2018 ASIL-B functional safety standard.

4. 4. The method of claim 1, wherein the first application is implemented redundantly.

5. 5. The method of claim 1, wherein the first application runs on the same processing platform as the map-based application.

6. The method of claim 5 , wherein the processing platform is executed by an electronic control unit (ECU) of the vehicle.

7. 7. The method according to any one of claims 1 to 6, The method, wherein the map tile data structure further comprises a digital signature for verifying authenticity and / or integrity of the map tile data structure, and wherein the digital signature for the map tile data structure is applied by a server, from which the map tile data structure is transmitted to the second application.

8. 2. The method of claim 1 , wherein the associated object level security data for an object includes a hash value calculated using at least the object data for the object, and wherein verifying the integrity of the object data includes the first application recalculating the hash value and comparing the recalculated hash value with the hash value for the object included in the map tile data structure.

9. 2. The method of claim 1, wherein the second application obtains object data and its associated object level security data and provides the requested object data and the associated object level security data to the first application, the first application uses the object level security data to verify the integrity of the requested object data, and if the verification of the requested object data fails, the first application generates an integrity error message and / or generates another request for the requested object data.

10. 2. The method of claim 1, wherein the second application is operable to obtain the requested object data by first checking whether the requested object data is present in the map tile cache; If the requested object data is present in the map tile cache, the second application reads the requested object data from the map tile cache; if the object data is not present in the map tile cache, the second application issues a request to the at least one remote server for the requested object data; the second application verifies the authenticity and / or integrity of the map tile data structure received from the at least one remote server using the associated digital signature before adding the object data to the map tile cache.

11. 1. A method of operating a client application executing on one or more processing units of a vehicle traveling over a navigable network within a geographic area to provide digital map data from at least one remote server to one or more map-based applications executing on an electronic control unit (ECU) of the vehicle, the method comprising: the client applications include a first application and a second application; the at least one remote server accesses a map tile metadata store that stores metadata for each of the map tiles in the map tile data store, each arc and node of a tile having object data and object level security data in the form of a hash value associated therewith, the hash value being calculated at the at least one remote server based at least on the object data for the individual arc or node and tile metadata for the tile that includes the object data for the individual arc or node; The second application includes a map tile metadata cache that stores the metadata for each of the map tiles in a map tile cache retrieved from the at least one remote server, and the method further comprises: receiving, by the first application, a request from the map-based application for digital map data relating to a feature of the navigable network; requesting, by the first application, from the second application, the object data and hash value for at least one arc or node related to the requested digital map data; obtaining, by the second application, the requested object data and hash value from the map tile cache, or from the map tile data store if the requested tile is not stored in the map tile cache, and providing them to the first application; requesting, by the first application, from the second application, the metadata for the map tiles relating to at least one arc or node relating to the requested digital map data; obtaining, by the second application, the requested tile metadata from the map tile metadata cache, or from the map tile metadata store if the requested tile metadata is not stored in the map tile metadata cache, and providing it to the first application; calculating, by the first application, a new hash value for the at least one arc or node based on the received object data and tile metadata; comparing, by the first application, the new hash value with the received hash value; and providing, by the first application, either the requested digital map data or an integrity error message to the map-based application based on the comparison.

12. 12. The method of claim 1, wherein the map tiles represent the navigable network within the portion of the geographic area as a plurality of arcs connected by nodes, and each arc and node of a tile has object data and object level security data associated therewith.

13. 13. The method of any one of claims 7 to 12, wherein the map-based application is an automated driving application or the map-based application is a vehicle horizon provider that in turn provides map data to an automated driving application; and wherein, upon failure to verify the requested object data based on the associated security data, the automated driving application operates the vehicle in a safe mode and / or brings the vehicle to a safe stop.

14. 14. A method according to claim 11 or claim 12 or 13 when dependent on claim 11, wherein the requested map metadata is transferred separately from the map data.

15. 15. An electronic control unit (ECU) of a vehicle running one or more client applications configured to perform the method of any one of claims 1 to 14.

Images