Digital map data with enhanced functional safety

Abstract

A technology for generating and providing secure and reliable digital map data is disclosed herein. The technology uses a simple and effective data structure to implement verification of the digital map data in a map client to check the correctness of the map data before the map data is delivered on-board to components that rely on the map data.

Description

Technical Field

[0001] The present invention generally relates to methods and systems for providing digital map data, for example, transmitted from a cloud server environment to a map-based application executed onboard a vehicle. Embodiments relate to methods and systems for providing such digital map data with enhanced functional safety. In particular, embodiments of the present invention relate to techniques for verifying the integrity (and authenticity) of high-definition (HD) map data, for example, before providing the HD map data for use in an advanced / autonomous driving application. Embodiments also relate to methods of operating a client application for such a context. Background Art

[0002] Navigation systems use digital maps to support drivers in reaching a desired destination. Such digital maps usually consist of a set of multiple navigable segments (or 'arcs') and nodes, which connect road segments together to form a suitable graphical representation of a navigable (e.g. road) network. Digital map elements have associated navigation cost parameters, which can be used to determine the cost of a path to a destination, e.g. for route planning purposes. Digital maps that support (only) basic road-level navigation and route planning services are sometimes called standard definition maps (SD maps).

[0003] In order to provide more advanced autonomous driving (AD) and advanced driver assistance system (ADAS) functionality, it is necessary to use so-called high-definition maps (HD maps) that provide extremely detailed and accurate three-dimensional views of both road and lane geometry. Therefore, 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, etc. A typical HD map therefore includes a set of arcs representing node areas and lane groups and a set of nodes that describe the connections between the arcs. Node areas and lane groups describe the road surface from one side to the other (and also along the direction of travel). HD maps actually extend the vehicle's field of view beyond the range of its local sensors and thereby achieve a smoother, safer and more efficient driving scenario.

[0004] It will be appreciated that AD / ADAS applications may provide highly automated driving functionality, the safety of which is largely dependent on receiving accurate and up-to-date HD map data reflecting the area of ​​the navigable (e.g. road) network within which the vehicle traverses. 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 may therefore have serious (even fatal) consequences.

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

[0006] Functional safety of in-vehicle safety-critical systems is typically achieved by developing systems that comply with the ISO 26262 functional safety standard. The generation of safety-critical map data will be subject to the ISO 21448 standard for Safety of Intended Functionality (SoTIF). Ensuring the reliability of such digital map data therefore places certain requirements on the development of map data delivery and distribution systems. However, it will be appreciated that due to the number of interfaces and functional components associated with a map distribution system, i.e., a map client (interface), such a map client (interface) is a functionally complex software component. Implementing a map data delivery and distribution system at the required functional safety level can therefore be both labor intensive and complex. Meeting the desired functional safety requirements of AD / ADAS applications therefore typically involves a significant burden of design, testing, and support of a map delivery and distribution system, with such complex implementations typically requiring increased processing and storage resources.

[0007] Digital map data for AD / ADAS applications is typically generated remotely (e.g., in a cloud server environment) by compiling appropriate source data from one or more map data sources and then delivering the map data from the cloud to the vehicles that require it. The onboard distribution network then distributes the map data to the AD applications that require it (and / or to any other map-based applications that execute onboard the vehicle) as needed.

[0008] In order to provide more efficient delivery of map data, it is well known to represent digital maps as a plurality of map tiles, each of which represents a portion of the overall map area and contains data indicating objects within the area covered by the map tile. For example, a set of map tiles may be provided with different map tiles in the set representing a navigable network (e.g., roads) in different parts of a geographic area as a plurality of arcs connected by nodes. Thus, at least object data for a set of arcs and nodes defining a navigable (e.g., road) network in that area may be stored for the map tile. This may include object data defining the characteristics of the arc / node itself and data for objects (e.g., traffic signs) associated with the arc / node, etc. (e.g., defining the road / lane geometry in that area). Of course, any other suitable information that may be desirably included in the map may be stored for the tile. When a map-based application requires information about a particular feature or location within a navigable (e.g., road) network, then a request may be issued for (several) relevant map tiles to obtain appropriate map (i.e., object) data.

[0009] Such requests are typically handled by a suitable client application (interface) executed on the vehicle. The client application (interface) receives (several) map image tiles, and then, processes these map image tiles accordingly to extract relevant map data. The client application (interface) can then distribute the map data to any, for example, AD / ADAS applications as needed. This is typically done with reference to a suitable "horizon" generated by considering, for example, the upcoming driving path predicted based on the current vehicle position, driving conditions, and road data. The horizon can then be associated with a set of map image tiles representing a sub-map in an area leading up to the horizon on which dynamic (e.g., sensor) data can be added, for example to implement AD / ADAS functionality. Typically, multiple horizons corresponding to multiple predicted driving paths are generated to be able to better interpret and adjust vehicles that deviate from any of the predicted driving paths.

[0010] The sub-map data associated with the (several) views may be provided to the AD / ADAS application, for example, according to the Advanced Driver Assistance System Interface Specification (ADASIS) protocol. For example, the new ADASIS V3 standard is commonly used for in-vehicle HD map distribution. ADASIS V3 consists of a view provider, a view reconstructor, and the ADASIS V3 protocol used between the provider and the (several) reconstructors. 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 may plan a predicted driving strategy, for example, by comparing the map data within the view with dynamic sensor data in the usual manner, etc.

[0011] Such systems thus allow map data to be delivered directly to the vehicle. However, when map data is provided as a set of image tiles, ensuring the functional safety of map data used by AD / ADAS applications may still be difficult. Furthermore, existing methods for achieving functional safety may be relatively complex to implement, and it is desirable to provide a more efficient client application (interface) that is able to achieve the required functional safety.

[0012] Applicants therefore believe that there is room for improvement in methods of providing map data while still meeting the desired functional safety requirements of, for example, AD / ADAS applications. Summary of the invention

[0013] According to a first aspect of the invention, there is provided a method of validating map data transmitted from a remote server to one or more map-based applications executed on an electronic control unit (ECU) of a vehicle traversing a navigable network covered by a digital map, wherein the digital map is represented as a set of a plurality of map image tiles, each image tile representing a specific geographical area comprising a portion of the navigable network, the method comprising:

[0014] generating at the server a data structure for a map image tile, wherein the data structure comprises object data indicative of a set of one or more objects that are at least partially within the geographical area covered by the image tile and / or within the geographical area covered by another one or more of the image tile(s) representing the digital map,

[0015] wherein for at least one object in the set of one or more objects whose object data is contained in the map image tile data structure, associated security data is contained in the map image tile data structure together with the object data for the at least one object, the security data being usable to verify the integrity of its associated object data; and

[0016] The map image tile data structure for the image tile including the object data and associated safety data is transmitted from the server to a client application executing on one or more processing units of the vehicle.

[0017] The present invention generally relates to the generation and provision of digital map data, and in particular to the provision of high definition (HD) digital map data suitable for advanced and / or autonomous driving applications. In particular for autonomous driving (AD) applications, it will be appreciated that map data is safety-critical and therefore its reliability must be ensured in order to meet the safety requirements of onboard safety-critical systems. Embodiments of the present invention therefore relate to methods for validating such digital map data, for example, before it is distributed to and used by map-based applications executed onboard a vehicle. In addition, developing a map client interface that is capable of meeting the desired safety requirements can be challenging and intensive. Therefore, embodiments of the present invention also relate to the effective implementation of a map client application with enhanced (e.g., ASIL-B) level of functional safety, as will be further explained below.

[0018] For example, in an embodiment of the first aspect of the present invention, a method for verifying digital map data at an "object level" is provided, which allows individual map objects to be verified in an efficient manner without significant additional storage and / or transmission overhead, even in cases where the map data is packed into several map image block data structures for transmission purposes, as will be further explained below.

[0019] It will be appreciated that such digital maps are typically complex data structures containing roads, road lanes, nodes, traffic information, points of interest, and many other types of information. Therefore, in order to reduce the amount of data that must be stored locally to a vehicle running a map-based application and / or to reduce the bandwidth required to transmit map data to the vehicle, the entire area represented by the digital map can be (and is in the present invention) divided into a plurality of smaller areas for data storage purposes, so that the device only needs to retrieve data related to the area related to its current location and / or predicted driving path. In the present invention, the smaller areas into which the entire area is divided for mapping purposes are referred to as "image blocks". However, it will be appreciated that other equivalent terms may be used, and the term "image block" does not imply any particular limitation on the shape or size of the areas into which the digital map is divided.

[0020] The use of this tile-based approach can help provide for more efficient transmission and distribution of map data from various map data sources to vehicles requiring the map data. For example, an advantage of the tile-based approach is that it is possible to easily compile map data from different sources at a server (or multiple servers) into a set of corresponding tiles, and then, for example, deliver or provide the relevant map data on a tile-by-tile basis to vehicles requiring map data for the area covered by the tile. The tile data structure(s) can then be unpacked, for example by a suitable client application (interface) executing on one or more processors onboard the vehicle in order to extract the desired (map) object data, which can then be distributed as needed to map-based applications running within the onboard environment.

[0021] Part of ensuring the reliability of map data and enhancing the functional safety of applications that rely on map data is able to verify the integrity and authenticity of the data delivered to the vehicle. To this end, the image block data structure can be (and in a preferred embodiment is) digitally signed so that it can be checked that the data structure received by the client application (interface) matches the image block data structure transmitted from the (several) original servers. Therefore, in an embodiment, after the image block data structure is compiled at the first server, each image block data structure can then be digitally signed at the (or another) server before it is delivered to the vehicle. For example, this can include adding a digital signature (such as a 256-byte SHA-2 digital signature or the like) to each image block data structure. This method allows the integrity and authenticity of the data to be verified at the image block level, that is, the level at which the data is obtained from the server. Therefore, when the image block data structure is transmitted from the server to the appropriate client application (interface) executed on the vehicle, before the client application (interface) attempts to use or distribute the map object data stored for the image block, the client application (interface) can check the digital signature to verify the integrity of the image block data structure. Of course, this image block-level verification does not require the use of digital signatures, and any other suitable verification technology may be used as desired.

[0022] This image block level verification is important, for example, to confirm that the image block data structure has not been altered or damaged during transmission. However, it will be appreciated that any terminal application that requires map data (which may be an AD application or an advanced driver assistance system (ADAS) application running on the vehicle's ECU, but may also include any other navigation or geospatial awareness application executed within the vehicle environment) will not typically use map data at the image block level, and instead requires access to object data that can be extracted from such image block data structures. The client application (interface) is therefore used in conjunction with or as part of the on-board map distribution network to extract relevant object data that can then be used by map-based applications from the data structure at one level, 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 map (object) data to, for example, a view provider, which then passes the map data to a map-based application. Other arrangements will of course be feasible.

[0023] 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 that will ultimately be provided to (several) map-based applications and thereby potentially used, for example, in autonomous driving vehicles, is reliable, and therefore, additional security measures may be required in order to ensure that relevant functional safety criteria for the (several) applications are met. For example, while verifying the tile data structure may allow verification of the authenticity of the object data contained within the tile data structure (i.e., by confirming that the data is from a reputable source, such as a verified server), it is recognized that the object data itself may still be altered during transmission and / or when stored and therefore the integrity of the object data should be desirably verified before it is provided to the map-based application, for example, in the event that the data is somehow corrupted or altered within the on-board map distribution network and / or when it is maintained locally, for example, in a cache associated with a 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 limiting the amount of additional data that needs to be distributed in the vehicle.

[0024] Therefore, it is an object of embodiments of the present invention that, at least for some objects within a particular image block data structure, security data is provided on a per-object level (preferably as a supplement to the image block level verification described above). That is, in a preferred embodiment, in addition to providing authenticity and / or integrity verification at the image block level (i.e., the level at which data is accessed from a server by a client application (interface)), the present invention (also) provides security data at the level of meaningful entities (i.e., objects for which data is stored in the image block data structure) that are ultimately used by map-based applications. The associated security data for the objects can be used (e.g., by the client application) to verify the integrity of the object data itself. Therefore, the image block data structure for at least some objects for which object data is stored contains associated security data to verify the integrity of the object data. In this way, it is possible to easily verify the object data for the object of interest and ensure that the relevant functional safety criteria can be met both before its on-board distribution and before it is used by any on-board application.

[0025] In particular, this means that it can be ensured that the object data has not been or has not been corrupted after being received (e.g., when storing or accessing the object data from a local data store accessible by a client application (interface)). Furthermore, in a preferred embodiment, this is done with relatively little additional processing overhead, and, for example, without having to develop the entire map data distribution system with the required security level, as will be explained further below.

[0026] The invention also extends to a map delivery (or generation) system for performing such a method. Thus, according to a second aspect, there is provided a map delivery system comprising: at least one remote server in communication with a client application (interface) executed on one or more processing units of a vehicle travelling within a navigable (e.g. road) network covered by a digital map, wherein the digital map is represented as a set of multiple image tiles, each image tile representing a specific geographical area comprising part of the navigable (e.g. road) network, wherein the at least one remote server is configured to: generate a data structure for a map image tile, wherein the data structure comprises object data indicative of a set of one or more objects at least partially falling within the geographical area covered by the image tile and / or within the geographical area covered by another one or more of the (several) image tiles representing the digital map, wherein for at least one object of the set of one or more objects whose object data is included in the map image tile data structure, associated security data is included in the map image tile data structure together with the object data for the at least one object, the security data being usable to verify the integrity of its associated object data; and transmit the map image tile data structure for the image tile comprising the object data and the associated security data from the server to the client application executed on the one or more processing units of the vehicle.

[0027] This second aspect of the invention may optionally include, 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. For example, even if not explicitly stated, the system may include, and in an embodiment does include, means for implementing any step or any step described with respect to the method herein in any of its aspects or embodiments (and vice versa).

[0028] In an embodiment, a digital map includes a plurality of hierarchies (or layers), wherein each hierarchy is divided into a plurality of tiles in the manner described above. That is, tiles may be arranged into a plurality of respective hierarchies, and each map tile may therefore contain object information for an associated hierarchy of a map. For example, different hierarchies of a map may be used to store different types of object data. Each map hierarchy may therefore contain a subset of available map information. For example, a basic hierarchy of a map may contain basic road geometry information (e.g., a set of arcs and nodes defining a navigable (e.g., road) network). Objects and / or attributes of different types may then be stored in the map at progressively higher levels. This structure advantageously allows (several) map-based applications that require map data to extract map data from any of the hierarchies, making it possible to (only) extract relevant information for map-based applications depending on which information the application requires.

[0029] The image blocks representing a map (or more specifically, a level in a map) may generally take any suitable form as desired. The image blocks may have regular or irregular shapes. For example, in some cases, the image blocks may follow regional boundaries (e.g., countries, states, provinces), and therefore may have irregular shapes and sizes. In other cases, and more generally, the image blocks into which the entire region is subdivided include a regular shaped tessellated array of cells. Typically, the image blocks may be rectangular (e.g., square), although other shapes such as pentagons, triangles, etc., including combinations of the shapes, may be appropriately used. All image blocks used for a map may have the same size. However, in an embodiment, it is also contemplated that the image blocks may have variable sizes. This may be the case of image blocks within a single level of a map or across different levels of image blocks. For example, in the latter case, instead of storing different types of data at different levels of a map (or as a supplement to this), different levels may be used to store map data at different granularity levels. In particular, providing variable tile sizes, whether within a single level of a map or across multiple map levels, can allow for data dependent sizing of tiles, where the physical size of the tiles is selected, for example, so that each tile data structure has approximately the same data size. This can help facilitate more efficient transmission of map data and more efficient use of available tile resources (and associated data amounts for tiles), particularly where the density of map data varies significantly. Thus, for relatively sparse (e.g., rural) areas, where there may be relatively little map content of interest, areas may be represented using relatively large tiles. On the other hand, relatively small tiles may be used to represent denser areas (e.g., urban areas) where there is likely to be a greater amount of map content that needs to be stored.

[0030] Each image block thus represents and is associated with a specific geospatial region within the entire area covered by the map. For each image block, then, a suitable data structure may be generated that describes any object that falls within the associated region of the image block and should be included in the map. The object whose data is stored for the image block may include any suitable object that may be desirably included in the map. The object may thus represent a real-world object, such as a road element, a node, a point of interest, a traffic sign, a traffic light, a speed camera, etc. However, digital map data also includes other types of information objects that may be used to encode map information. For example, an object may be used to identify a location where a speed limit changes or to provide a virtual node between road elements. The object whose data is stored for a particular image block may include any such object. It will also be appreciated that the data stored in the image block data structure is not limited to data indicating an "object" and may include any other suitable data, such as data that may be desirably included in the map. For example, in an embodiment, the image block data structure also includes data indicating any attribute (such as a speed limit) associated with a navigable (such as a road) network. Any such attribute data may also be stored along with appropriate security data in a manner similar to that described herein for object data.

[0031] It will be appreciated that the core information of an HD map, whose reliability must be ensured, is a number of sets of arcs and nodes representing nodal areas and lane groups associated with a navigable (e.g. road) network. The object whose object data is stored for an image block will therefore typically contain at least object data for a set of arcs and nodes representing a road network in the area of ​​the map covered by the image block. Therefore, in embodiments it will be understood that any reference to an object or object data herein refers to (at least) arc and / or node data or object data associated with an arc / node.

[0032] It will be appreciated that although the above-described manner in which digital maps are divided into tiles of smaller areas may be useful for reducing storage requirements, this method will introduce tile boundaries that need to be resolved. For example, because people / vehicles are usually likely to move from one tile to a neighboring tile, there will be map objects (roads, nodes, points of interest, etc.) across tile boundaries. That is, at least some map objects may (and at least some will usually) comprise elements extending across multiple tiles. In such cases, in order to avoid having to split object data, object data may be (and in some preferred embodiments be) copied and stored in each of the tiles on which the element extends. This may be useful because it avoids the need to attempt to 'join' objects that occur in different tiles across tile boundaries. In this case, security data is stored together with object data for each of the related tiles. However, other methods for storing such data will certainly be feasible. For example, in another preferred embodiment, object data for a particular object may be stored (only) in a single tile data structure, even in the case where the object represents an element extending across multiple tiles, so that then (only) the object data is stored (directly) in a single tile. For any other tiles within which the object at least partially falls, then, a suitable reference or pointer to the tile data structure containing the relevant object data is generated and stored. Thus, in some embodiments, when an object extends across multiple adjacent tiles in a particular level of the map, the object data may be stored (only) in a first tile, and the other tiles within which the object falls reference the first tile. Similar references may be made between tiles at different levels, for example, so that object data appearing in a tile at a first level is stored for a tile at a second level, then, a suitable reference to the tile at the second level is included in the tile at the first level.

[0033] It will therefore 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 directly indicative of the object), or may be data indicative of the object only indirectly, for example in the form of a suitable pointer to another tile data structure at which the object data is stored. Correspondingly, the tile data structure may therefore contain data not only for objects falling within the area covered by its respective tile, but also for objects falling at least partially within the area of ​​another tile (which may for example be an adjacent tile in the same level of the map as the tile in which the data is stored, or a tile on another level). In this case, the security data for 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).

[0034] However, various other arrangements for storing data indicating objects for image blocks will be feasible in principle. In fact, in general, data indicating objects for a particular image block can be stored in any suitable manner. For example, the data can indicate objects in any manner, and as long as there is a suitable association that allows the relevant object information to be extracted and properly used, this does not imply any characteristic form of relationship between the data and the object. The object data can be stored directly or indirectly in the data structure for the image block. In addition, the data can be stored in compressed or uncompressed (original) format as required.

[0035] The security data associated with the object may take any suitable form as required. Various techniques for verifying the integrity and / or authenticity of the data are well established and can be used as required. In a particularly preferred embodiment, the security data includes a 64-bit truncated SHA-256 hash value (or hash 'code'). It is found that this provides an appropriate trade-off between the reliability and implications of storage space and cellular network use. The secure hash can also be easily implemented at the desired functional safety level. For example, the security data can also be provided in the form of a digital signature, for example. However, checking the digital signature is more complex than (re)calculating the hash value and therefore more difficult to implement, especially when the system is designed according to a higher functional safety level (e.g., at ISO26262:2018 ASIL-BASIL-B or higher). Therefore, in an embodiment, for at least some objects in the image block data structure whose security data is stored (and preferably for each of the objects), the security data can be provided in the form of a secure hash (value) of the object data calculated at the server. The object data can therefore be verified at the client application (interface) by recalculating the hash value based on (at least) the object data and comparing this with the hash value contained in the security data. In a preferred embodiment, the map image block metadata is also transmitted separately from the map data. The metadata may include, for example, version and format information for the image block and / or the 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 for the image block of the object data is also stored. The metadata is preferably also protected by the hash. That is, the map image block preferably has associated metadata, which has its own hash.

[0036] However, other arrangements for authenticating object data and metadata will certainly be feasible and it is not necessary to use a secure hash. For example, it will be appreciated that in other embodiments, the security data may alternatively or additionally include any suitable error detection code (e.g., minimum distance code, hash code, checksum code, parity check code, cyclic redundancy check, etc.), error correction code (block code, convolutional code, Hamming code, Viterbi code, etc.), message authentication code, digital signature, or the like. Furthermore, any combination of these techniques may be applied in embodiments.

[0037] As implied above, security data for each object whose object data is stored for a particular image block can be stored. Security data for each object can be stored individually, i.e. one-to-one correspondence. Alternatively, security data can be associated with object data for a group of one or more (e.g., multiple) objects (e.g., a group of objects that can be accessed together in general) and stored for the object data. However, it is not necessary to store security data for each segment of object data contained in the image block data structure, and in some embodiments, security data for less than all objects within a particular image block data structure is stored. For example, it can be that security data for only certain (e.g., safety-critical) objects is stored. This can involve storing security data for objects in the basic hierarchy of a digital map only. Alternatively, different types of security data for different types of objects in different hierarchies of, for example, a map can be stored to provide different levels of verification.

[0038] For example, it will be appreciated that road geometry elements such as arcs (lane groups, node areas) and nodes are essential elements of HD maps and core safety-critical entities of HD map applications. At least the safety data of these objects should therefore be (and are) stored. Therefore, 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, wherein each arc and node of the tile has object data and safety data (e.g., hash values) associated therewith. For example, in a particularly preferred embodiment, a hash value (or hash code) for each arc (e.g., a lane group or node area) and node whose data is stored is calculated at the server, and then the hash value is added to the tile data structure together with the object data describing the arc / node. The hash value preferably covers not only the object data but also any associated metadata for the tile in which the object is stored. Therefore, each arc and node for which the object data of the tile is stored has an associated hash value, and this is preferably based not only on the object data but also on the associated tile metadata (calculated based on the two) for the tile containing the object data. When the data structure containing object data and hash values ​​for arcs / nodes is unpacked at the client application (interface), the hash values ​​for the arcs / nodes can then be recalculated by the client application (interface) based on the received object data (preferably and associated metadata (sent separately) on which the hash values ​​are also based), and then the recalculated hash values ​​are compared with the original hash values ​​calculated at the server to verify the integrity of the object data. In an embodiment, the image block metadata transmitted separately from the map data is also protected by the hash. The client application (interface) can therefore perform similar calculations and comparisons on the image block metadata to check its integrity before the metadata is used to check the integrity of the object data in the image block. Therefore, the method generally includes the client application unpacking the image block data structure to extract object data indicating one or more objects whose data is stored in the image block data structure, and the client application verifies the integrity of the extracted object data using the associated security data.

[0039] However, various other arrangements would of course be possible, eg depending on the type of security data being provided.

[0040] It may not be necessary to store safety data for other non-critical objects. Nevertheless, in a preferred embodiment, safety data for other objects in the map is also stored. For example, in a preferred embodiment, objects associated with particular arcs and nodes at higher levels in the map (which may be speed limits, driving restrictions, etc.) get an associated hash covering the associated object data and an index reference to the arc or node to which the object data is associated. Note that lane groups and node areas may contain "key or index references" to their two associated nodes. Then, because they are covered by the hashes of lane groups and node areas, the integrity of any sub-map can be guaranteed.

[0041] When the object data has been properly verified, for example using its associated safety data, for example in the manner described above, then, and can be properly used and distributed to any map-based application that requires map data. On the other hand, when the object data cannot be verified, that is, because the safety check fails, a suitable integrity error signal can be generated. Alternatively or in addition, when the verification fails, the client application (interface) can make another attempt to obtain the object data. For example, multiple attempts can be made until a timeout criterion is met (for example, a certain period of time has passed or a certain number of attempts have been made), at which time, a suitable integrity error signal can be generated. Then, the integrity error signal is preferably passed to (several) map-based applications and acts accordingly. For example, when the map-based application is an autonomous driving application (or where the map-based application is a vehicle view provider, which in turn provides map data to the autonomous driving application), when the integrity error message is generated, then, the autonomous driving application can operate the vehicle in a safe mode and / or stop the vehicle safely.

[0042] The image block data structure for representing the image block of the digital map is generated at the central server, and then, can be transmitted from the server to any vehicle traveling in a navigable (e.g., road) network and communicating with the server when necessary. The client application (interface) executed on the vehicle can use any suitable wireless communication protocol to communicate with the server. In an embodiment, the communication is performed using the HTTPS protocol (via TLS). All messages transmitted between the TLS server and the TLS client are encrypted and remain private even if intercepted. TLS provides message integrity by calculating message digests. Certificate verification based on certificate chain enables the TLS client (i.e., the part of the client application (interface) communicating with the server) to authenticate the data (i.e., map image block data and map image block metadata) provided from the TLS server. However, other arrangements will certainly be feasible.

[0043] It will be appreciated that, as used herein, a "server" may generally refer to a group of one or more servers or one or more server clusters. In particular, it will be appreciated that a server need not be a (single) physical data server, but may include, for example, a virtual server running a cloud computing environment. Thus, the server may be a cloud server. It will also be appreciated that a vehicle may receive map data from multiple servers, for example, it may obtain map data for corresponding multiple map data sources. Therefore, any reference to a server herein should be understood to mean "at least one server", except where the context requires otherwise. Various other arrangements will of course be possible.

[0044] The server may therefore typically include an image block generator that is able to access a database of digital map data and image block parameters indicating the manner in which the digital map data should be classified into image blocks. The image block generator may be implemented by a digital map compiler. The digital map compiler compiles map information in one format obtained from the database into another format, such as a format that complies with standardized map specifications (NDS, OSM, etc.), or generates map information for a specific application (car navigation, pedestrian navigation, vehicle type-specific navigation, public transportation navigation, ADAS system, autonomous vehicle control, etc.). For example, a map compiler may be provided by a back-end application that can compile map information using proprietary information. The map compiler uses digital map data such as presented in a presentation form (e.g., as presented in a digital map database) and generates image blocks. Each image block contains digital map data related to a predetermined area covered by the digital map. That is, a digital map is typically generated by obtaining a set of map source data from a server, classifying the map source data into corresponding levels and / or image blocks of the digital map, and then compiling the image block data structure accordingly. The data included in the map may be obtained from multiple different sources. It will be appreciated that the map data may be added to the image block data structure in any suitable format. For example, the object data may be stored directly or indirectly in the data structure for the image block. In addition, the data may be stored in compressed or uncompressed (raw) format as desired. Preferably, the data is compressed to facilitate transmission.

[0045] Once the map image block data structure for a particular image block has been compiled, the generated image block data structure can be stored in a suitable map image block data storage area (e.g., a database) at a server together with the corresponding image block data structures for other image blocks representing the digital map. Therefore, although the embodiment is described with respect to generating a data structure for a single image block, it will be appreciated that the image block data structure for each image block representing the map will be generated in the same manner as presented above. Then, the image block data structure for the map image block (or at least the latest version thereof) is stored in a suitable map image block data storage area on the server. The server therefore includes a map image block data storage area. Therefore, in an embodiment, the method includes storing (several) image block data structures in a map image block data storage area on the server, which can then be retrieved from the server to be transmitted from the server to any vehicle that needs the map data stored in the image block data structure. The server preferably also includes a metadata data storage area to store the associated metadata sent to the vehicle together with the map image block data storage area. The image block data structure can be used to be transmitted to the vehicle from the map image block data storage area in a manner that will be further described below, for example in response to a request for information about features or areas defined with a digital map. The tile data structure will also be updated over time. Therefore, a group of specific map tiles can together form a digital map with a specific 'map version'. Each map tile in the map has its own associated 'tile version'. It will be appreciated that tile versions can be associated with multiple map versions. Tile versions and map version information are preferably stored and transmitted via metadata associated with the tile data structure. Therefore, multiple metadata records may exist for each map tile. A specified map version should typically be the latest map version available on the server (if connectivity is available to make latest version calls to the server via the first and second applications) or the latest map version used (if there is no connectivity).

[0046] Then, the image block rendering application can retrieve the data structure from the map image block data storage area as needed, for example, based on the current position of the vehicle or other locations of interest to be transmitted from the server to the vehicle requiring map data. The image block data structure can therefore be selectively transmitted (e.g., delivered) from the map image block data storage area to a client application (interface) executed on the vehicle, and the relevant map data can ultimately be distributed from the client application (interface) to (several) map-based applications requiring map data. For example, a map-based application can generate a request for data related to a specific real-world feature or geospatial area or location within a navigable (e.g., road) network. It will be appreciated that map-based applications do not use data at the image block level. Therefore, feature requests must be converted into appropriate requests for object data (e.g., related to arcs or nodes), which can be performed at the image block level. In an embodiment, a client application (interface) running on a computer device associated with the vehicle is used to process such requests to obtain the required map data. For example, the client application (interface) can unpack the image block data structure to extract data indicating 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, be executed at least partially on one or more electronic control units (ECUs) of the vehicle.

[0047] In a preferred embodiment, the client application is divided into a first application (client front end) and a second application (client back end) that communicate with each other. This can provide a particularly efficient implementation for achieving a desired functional safety level, as will be explained further below.

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

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

[0050] The second application (client backend) is therefore used as an interface between the server and the first application (client frontend). The second application is therefore operable to issue a request for digital map data to at least one server. In order to reduce the delay associated with such requests, at least some object data and security data received from the server can be and preferably are stored locally, for example, in a suitable high-speed cache accessible by the second application. Therefore, when such data is requested by the first application to the second application, the second application can first try to obtain the data from the associated high-speed cache. If the data is not available in the cache (there is a cache miss), then the data is obtained from the server. On the other hand, if the data is already available in the cache (cache hit), then this can be immediately provided to the first application for verification, etc. Object data and security data can be periodically evicted from the cache, for example, based on a suitable cache management strategy. The second application therefore preferably includes one or more caches to locally store image block data structures and image block metadata. For example, the second application can include a map image block cache storing multiple image block data structures obtained from a remote server. The second application preferably also includes a map tile metadata cache that stores associated metadata for each of the tile data structures that have been obtained from the remote server. The second application can then obtain any map data requested by the first application from the cache (if the data is available in the cache) or from the server when necessary. The second application (client backend) also preferably performs its desired verification / authentication as the tile data structure is received from the server and added to the cache. For example, when the tile data structure is digitally signed, the second application (client backend) preferably checks the digital signature to verify the tile data structure. That is, tile-level verification is delegated to the second application (client backend), while object-level verification is delegated to the first application (client frontend).

[0051] Thus, in an embodiment, a method comprises: receiving, by the first application, from the map-based application, a request for digital map data regarding a feature of the navigable network; requesting, by the first application, from the second application, the object data and security data (e.g., hash values) for the at least one arc or node associated with the requested digital map data; obtaining, by the second application, the requested object data and security data (e.g., hash values) from the map tile cache or, if the required tile is not stored in the map tile cache, from the map tile data store and providing them to the first application. Associated tile metadata may also be sent, e.g., as explained above. Thus, the method may further comprise: requesting, by the first application, from the second application, the metadata for the map tile regarding the at least one arc or node associated with the requested digital map data; obtaining, by the second application, from the map tile metadata cache or, if the required tile metadata is not stored in the map tile metadata cache, from the map tile metadata data store and providing it to the first application. The first application may 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: 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 providing, 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 a hash value determined based on (at least) the object data and associated tile metadata for the tile in which the object data is stored. Thus, the calculation of the new hash value may be performed using the object data and the associated tile metadata.

[0052] The client application (interface) therefore converts requests for information from (several) map-based applications (which may be requests for information about any characteristic feature or area within a digital map) into requests for object data associated with such features to allow the relevant object data to be retrieved from its associated image block data structure. The benefit of dividing the client application into a first application (client front end) and a second application (client back end) in the manner described above is that the functional safety requirements can be completely delegated to the first application (client front end). For example, it is preferred that the first application performs any desired validation of the object data before ultimately distributing the object data to the map-based application that generated the request. The first application (client front end) should therefore be developed to meet the strict functional safety procedures required to ensure the reliability of such data. However, this means that the second application (client back end) then does not need to meet such strict safety procedures.

[0053] For example, the ISO 26262 functional safety standard for road vehicles defines four automotive safety integrity levels (ASILs), namely ASIL-A, ASIL-B, ASIL-C, and ASIL-D. ASIL-D indicates the highest safety integrity level (where ASIL-A indicates the lowest safety integrity level). An additional class of QM (quality management) is used to indicate when no safety requirements are indicated. Developing high ASIL products is complex and labor-intensive and costly due to the heavy requirements on the development process. However, the ISO26262 standard defines an ASIL decomposition method that allows requirements with high ASIL to be decomposed into two or more requirements with the same or lower ASIL. By applying this method, the part of the system that needs to be implemented at a high ASIL can be limited to, for example, the first application (client front end).

[0054] For example, it is generally expected that the in-vehicle HD map delivery system is developed at least under ASIL-BASIL-B. By dividing the client application as stated above, the first application (client front end) can be developed under the ASIL-BASIL-B standard (or higher standards as required). This implementation may involve the use of any suitable measures to explain random and / or systematic failures. For example, random failures may cause changes in the code, stored data, or I / O data of the running software application. On the other hand, systematic failures may occur due to errors in the requirements, design, or implementation of the software application. The reduction of random failures can be achieved, for example, by adding runtime testing, fault detection, fault monitoring, redundant execution, and redundant diversified implementation schemes. For example, increasing the number of (separately developed) implementation schemes of modules in the software application makes the module less susceptible to random failures, because random failures are extremely unlikely to cause the same effect in two implementation schemes. This can be detected in the software application. Such diversified software modules also reduce systematic failures, because different implementation schemes are unlikely to have the same software errors. When designing the first application (client application) at the desired functional safety level, any of these techniques can be used. For example, in an embodiment, the client application can be implemented at least partially redundantly.

[0055] However, the second application (client backend) that interfaces to the server does not need to meet such requirements. Therefore, in a particularly preferred embodiment, the first application is developed at an ASIL-BASIL-B level (or higher), while the second application is preferably developed at a lower functional safety level. This also helps to simplify the entire map distribution system, since it is not necessary to develop an interface to the server (i.e., the second application (client backend)) at the same level as the client front end (e.g., at an ASIL-B level). This can be much more efficient than trying to implement the entire system at the required (e.g., ASIL-B) functional safety level, including interfaces to external servers. Therefore, in practice, according to a preferred embodiment, the retrieval and authentication of map image blocks can be performed (and performed) independently of the verification of object data within the map image blocks. This allows functional safety requirements to be met without significantly increasing the complexity of the system.

[0056] For example, as mentioned above, image block level authentication / verification is preferably performed by the second application (client backend), preferably using digital signatures that have been applied to the image block data structure at the server. It will be appreciated that digital signatures can be easily implemented, for example, under the ASI-QM standard, but may be more difficult to implement at higher safety levels (such as ASIL-B). On the other hand, object level verification is preferably performed by the first application (client frontend) under the ASIL-B standard (or higher). For example, object level verification is preferably performed as described above using, for example, hash values, which can be easily implemented at the desired safety level.

[0057] Thus, after the second application (client backend) has verified the authenticity / integrity of the image block data structure, the first application (client frontend) can then perform another verification to verify the integrity of the object data received from the second application (client backend) before passing the object data onward (e.g., ultimately to the (several) map-based applications). In this way, the client application (interface) can be implemented in an efficient manner at a desired functional safety level.

[0058] If the verification fails, this may be signaled to the map-based application as an integrity error. The first application (client front end) may attempt to retry fetching the data. In the event that the object data is safety-critical and the verification fails, the map-based application may then enter a "safe mode" by, for example, disabling the automated driving system or bringing the car to a safe stop. It will be appreciated that the map-based application may be any application that may require map data. Preferably, this is an AD or ADAS application, as it is in this context where map data may be safety-critical and therefore must be verified. Similarly, the map-based application may include a vehicle view provider, which in turn provides map data to an autonomous driving application. Therefore, in an embodiment, the map-based application is an autonomous driving application or wherein the map-based application is a vehicle view provider, which in turn provides map data to an autonomous driving application. However, in principle it may also be used to deliver map data to any other navigation or geospatial awareness application executed within the environment of the vehicle.

[0059] From another aspect, at a client side, there is provided a method of operating a client application executing onboard a vehicle traversing a navigable network in a geographic area covered by a digital map, wherein the digital map is represented as a set of a plurality of map image tiles, each image tile representing a particular geographic area comprising a portion of the navigable network, and wherein each map image tile has an associated map image tile data structure comprising:

[0060] object data indicative of a set of one or more objects at least partly lying within the geographical area covered by the map image tile and / or within the geographical area covered by another one or more of the map image tile(s) representing the digital map; and

[0061] security data for verifying the integrity of the object data associated with at least one object whose object data is stored in the map image tile data structure,

[0062] The method comprises:

[0063] receiving, at the client application, from one or more map-based applications, a request for map data associated with one or more features of the navigable network;

[0064] Obtaining, by the client application, object data associated with the feature(s) from the corresponding map image tile data structure;

[0065] obtaining associated security data for said obtained object data from said corresponding map image tile data structure; and

[0066] The client application verifies the integrity of the object data using the security data and, when the data is verified, passes the object data to the map-based application(s).

[0067] From another aspect, there is provided a client application executed onboard a vehicle traversing a navigable (e.g., road) network covered by a digital map, wherein the digital map is represented as a set of a plurality of map tiles, each tile representing a particular geographic area comprising a portion of the navigable network, and wherein each map tile has an associated map tile data structure comprising: object data indicating a set of one or more objects that are 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 tile(s) representing the digital map; and security data for authenticating the client application to the vehicle in interaction with the map tile. The client application is configured to: receive a request for map data associated with one or more features of the navigable network from one or more map-based applications; obtain object data associated with the (several) features from the corresponding map image block data structure; obtain security data associated with the obtained object data from the corresponding map image block data structure; and verify the integrity of the object data using the security data, and when the data is verified, pass the object data to the (several) map-based applications.

[0068] From another preferred aspect, a method is provided for operating a client application running on one or more processing units of a vehicle traversing a navigable network in a geographic area to provide digital map data from at least one remote server to a map-based application running on an electronic control unit (ECU) of the vehicle, wherein: the client application includes a first application and a second application, the first application communicates with the map-based application and the second application, and the second application communicates with the at least one remote server; the at least one remote server is capable of accessing: (i) a map tile data storage area storing a plurality of map tiles, each map tile representing the navigable network in a portion of the geographic area as a plurality of arcs connected by nodes; and (ii) ) a map tile metadata data store storing metadata for each of the map tiles in the map tile data store, wherein each arc and node of the tile has object data and a hash value associated therewith, the hash value being calculated based at least on the object data for the corresponding arc or node, and the tile metadata for the tile containing the object data for the corresponding arc or node; and the second application comprises: (i) a map tile cache storing a plurality of map tiles obtained from the at least one remote server; and (ii) a map tile metadata cache storing the metadata for each of the map tiles obtained from the at least one remote server, the method comprising:

[0069] receiving, by the first application from the map-based application, a request for digital map data regarding features of the navigable network;

[0070] requesting, by the first application program, from the second application program, the object data and the hash value for the at least one arc or node associated with the requested digital map data;

[0071] obtaining, by the second application, the requested object data and hash value(s) from the map tile cache or, if the required tile is not stored in the map tile cache, from the map tile data store and providing them to the first application;

[0072] requesting, by the first application to the second application, the metadata for the map image tile regarding the at least one arc or node associated with the requested digital map data;

[0073] obtaining, by the second application, the requested tile metadata from the map tile metadata cache or, if the required tile metadata is not stored in the map tile metadata cache, from the map tile metadata data store and providing it to the first application;

[0074] calculating, by the first application, a new hash value for the at least one arc or node based on the received object data and image block metadata;

[0075] comparing, by the first application, the new hash value with the received hash value; and

[0076] The requested digital map data or an integrity error message is provided by the first application to the map based application based on the comparison.

[0077] The method of operating a client application (interface) described above may be advantageous in itself in order to meet functional safety requirements, whether or not object-level verification is used. For example, delegating functional safety to the front end allows this to be isolated from map image block access, which can help simplify access requests and avoid having to build an entire map distribution system including a server interface at a high (e.g. ASIL-B ASIL-B) level. Instead, ASIL-B requirements are met by decomposing the client application into a relatively safe front end and a less safe back end. The present invention therefore also extends to in-vehicle distribution systems based on the above principles. In that case, the first application (client front end) should preferably run on the same ECU as the map-based application (although this will not be essential), and the map data returned to the map-based application is extracted from the object data obtained from the associated map image block.

[0078] Thus, from another aspect, there is provided a method of operating a client application running on one or more processing units of a vehicle traversing a navigable network in a geographic area to provide digital map data from at least one remote server to a map-based application running on an electronic control unit (ECU) of the vehicle, wherein: the client application comprises 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 having access to a map tile data store storing a plurality of map tiles, each map tile representing the navigable network in a portion of the geographic area as a plurality of arcs connected by nodes, wherein each arc and node of the tile has object data associated therewith; and the second application comprises a map tile cache storing a plurality of map tiles obtained from the at least one remote server, the method comprising:

[0079] receiving, by the first application from the map-based application, a request for digital map data regarding features of the navigable network;

[0080] requesting, by the first application to the second application, the object data for the at least one arc or node associated with the requested digital map data;

[0081] obtaining, by the second application, from the map tile cache or, if the requested tile is not stored in the map tile cache, from the map tile data store, the requested object data and providing it to the first application;

[0082] identifying, by the first application, the portion of the object data corresponding to the feature of the navigable network; and

[0083] The requested digital map data is provided to the map-based application by the first application using the identified portion of the object data.

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

[0085] The present invention also extends to map data delivery and map data distribution systems for performing the methods described above with respect to any of the aspects and embodiments of the present invention. For example, a map data delivery / distribution system may include a server in communication with one or more vehicles, the server including suitable map generation circuitry (including a map image block compiler, etc.), one or more data storage areas for storing the map image block data and metadata, and a transmission circuit for transmitting the map image block data structure to the vehicle. The vehicle includes one or more processors that execute various client applications that handle the map image block data structure and one or more map-based applications running on an engine control unit (ECU) of the vehicle that requires the map data. Such a system may be arranged to perform any (or all) of the method steps described herein. For example, the system may include a set of one or more processors that are operable or configured to implement the steps mentioned. Any step may be implemented by one of the processors or by multiple processors.

[0086] The various functions of the technology described herein can be implemented in any desired and suitable manner. For example, the steps and functions of the technology described herein can be implemented in hardware or software as needed. Therefore, for example, unless otherwise indicated, the various processors, functional elements, levels and "components" of the technology described herein may include any (any) suitable processors, controllers, functional units, circuit systems, processing logic, microprocessor arrangements, etc. that can be operated to perform various steps or functions, etc., such as programmable suitable dedicated hardware elements (processing circuit systems) and / or programmable hardware elements (processing circuit systems) that can be operated in a desired manner. For example, the components for implementing any of the steps of the method according to any of the aspects or embodiments described herein may generally include a group of one or more processors (or processing circuit systems) that are configured, such as being programmed with a set of computer-readable instructions to complete such operations. A given step can be implemented using a group of processors that are the same or different from any other step. Any given step can be implemented using a combination of several groups of processors. The system may further include a data storage component, such as a computer memory, for storing at least one repository containing instructions and information data. Any of the methods according to the present invention can be implemented at least in part using software such as a computer program. The present invention therefore also extends to a computer program product comprising computer readable instructions executable to perform or cause a system and / or server to perform a method according to any of the aspects or embodiments of the present invention. The present invention therefore extends to a preferably non-transitory computer program product comprising computer readable instructions executable when run 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 aspects or embodiments of the method described herein.

[0087] It should be noted that references to objects, features, regions, etc. associated with image blocks or image block data structures herein should be referred to as data indicating these, unless the context otherwise requires. Data may indicate related items in any manner, and may directly or indirectly indicate related items. Therefore, any reference to objects, features, regions, image blocks, etc. may be replaced by references to data indicating them. It should also be noted that the phrases "associated with" or "indicating" should be interpreted as requiring any specific restrictions on data storage locations. The phrases only require that the features are identifiably related.

[0088] Various features of embodiments of the invention are described in greater detail below. BRIEF DESCRIPTION OF THE DRAWINGS

[0089] Various embodiments will now be described, by way of example only, and with reference to the accompanying drawings, in which:

[0090] Figure 1 Describe an overview of the map delivery system;

[0091] Figures 2 to 8 schematically showing how a digital map may be compiled according to an embodiment, wherein the digital map comprises a plurality of layers each represented using a plurality of image tiles;

[0092] Fig. 9 Schematically illustrating a cloud-based map delivery system according to an embodiment, wherein map data is delivered from a cloud to a vehicle running one or more map-based applications;

[0093] Fig.10 Schematically showing a client application for handling map data according to an embodiment;

[0094] Fig.11 schematically illustrates a cache that may be used to locally store map data according to an embodiment;

[0095] Fig.12 Schematically illustrating a cloud-based map data distribution system according to an embodiment;

[0096] Fig.13 Another variant map data distribution system according to the embodiment is shown; and

[0097] Fig.14 Another example is shown in which a single map front end is served by multiple map clients according to an embodiment.

[0098] Like reference symbols will be used for like elements in the drawings where appropriate. DETAILED DESCRIPTION

[0099] The present invention generally relates to methods of obtaining digital map data for geospatially aware map-based applications, in particular autonomous driving (AD) and advanced driver assistance systems (ADAS) applications, where the reliability and accuracy of the digital map data is safety critical. An example of an effective implementation of a map client application executed onboard a vehicle with enhanced (e.g., ASIL-BASIL-B) levels of functional safety will now be described.

[0100] Functional safety is important when automated functions have a potential impact on humans. Such automated functions are often required to meet certain standardized functional safety levels by regulators, clients, or users. Meeting such functional safety requirements has a significant impact on the design, testing, and support of implementations during the product lifecycle. The technical impact of implementations of automated functions according to functional safety requirements can be substantially larger and more complex implementations. This can be visible, for example, in terms of increased code size and required data storage for functional safety implementations.

[0101] Functional safety involves ensuring that the implementation will operate as expected. This means that the implementation needs to consider the impact of both random failures and systematic failures. Random failures are introduced through material aging effects, through external factors such as vibration, temperature, humidity, radiation, etc. Random failures can cause changes in the code, stored data, or I / O data running the software application. Systematic failures can occur due to errors in the requirements, design, or implementation of the software application. The purpose of functional safety design practice is to reduce systematic failures by adopting rigorous development practices that are expected to substantially reduce the probability of systematic failures. The reduction of random failures can be achieved, for example, by adding runtime testing, fault detection, fault monitoring, redundant execution, and redundant diversified implementation schemes.

[0102] The increased fault tolerance of an implementation developed with a functional safety design approach comes at the expense of doubling or tripling the cost of hardware, software, development, testing, and maintenance.

[0103] Figure 1 Depicting an overview of a map delivery system 10, the map delivery system 10 includes a map compiler 12 and tile metadata service 14 deployed on a cloud server system 16, a tile data service 18 deployed on a content distribution 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 are also referred to as "cloud services".

[0104] The map compiler 12 receives map data from a suitable map generation unit 24 located on the cloud server system 16. The map generation unit 24 receives map source data from various data sources 26 and then converts this into a suitable format for inclusion into a digital map. The map compiler 12 then sorts the map data into corresponding layers and image tiles of the digital map, as will be further described below.

[0105] In this way, the map delivery system 10 is able to deliver map data from the map generation unit 24 in the cloud directly to the autonomous driving application 11 executing on the electronic control unit (ECU) of the vehicle 9 using the map client 22 .

[0106] Figure 1 The functional modules of the map client 22 and the interfaces to the map server infrastructure and to the various functional modules in the vehicle are shown. For example, Figure 1 The map client 22 includes six components, namely, a map interface adapter 101, a client library 102, a persistent cache 103, an image block validator 104, an HTTPS client 105, and a controller 106. The functions of these components will be described below. Fig.11 However, the map client that has been Figure 1 It is understood that due to the number of interfaces and the number of functional components in the map client, the functional safety implementation of the map client is both complex and may require a large amount of resources (computing power, storage requirements, energy consumption, etc.).

[0107] Figure 1 The map delivery system 10 shown in FIG. 1 is generally operable to deliver required digital map data to any map-based application executing onboard a vehicle requiring the map data. The digital map data is generally complex.

[0108] For example, it will be appreciated that a digital map typically includes a number of map objects representing real-world objects, such as navigable elements, nodes, points of interest, etc. of a navigable (e.g., road) network. A navigable (e.g., road) network is typically a network comprising a plurality of interconnected (e.g.,) roads that can be navigated by a vehicle. A navigable (e.g., road) network can typically be represented by a digital or electronic map (or mathematical graph). In its simplest form, a digital map is effectively a database containing data representing nodes, most typically road intersections, and arcs between those nodes representing roads between those intersections. In a more detailed digital map, an arc can be divided into segments defined by a start node and an end node. These nodes can be "real" in that they represent road intersections where a minimum of three lines or segments intersect, or they can be "artificial" in that they are provided as anchor points for segments that are not defined at one or both ends by real nodes to provide (among other things) shape information for a particular stretch of road or a component identifying a location where a certain characteristic of that road (e.g., speed limit) changes along the road. In almost all modern digital maps, nodes and arcs (or segments of arcs) are further defined by various attributes, again represented by data in a database. For example, each node will typically have geographic coordinates to define its real-world location, such as latitude and longitude. A node will also typically have maneuver data associated with it, which indicates whether it is possible to move from one road to another at an intersection. For the purpose of conventional navigation guidance, for example, as can be provided by a known portable navigation device, the elements of a digital map only need (and typically will only need) to contain information about the centerline of the road, although each road segment may also be supplemented with attributes such as maximum permitted speed, lane size, number of lanes, whether there are dividers between them, etc. However, according to an embodiment of the present invention, as will be further described below, a digital map may be generated (or used) that provides a more accurate and more realistic representation of the road profile including lane centerlines and lane connectivity (i.e., lane markings) as well as other key elements, such as, for example, three-dimensional geometry of a navigable (e.g., road) network, such as landmark objects that may be desirably incorporated into the map. This type of digital map may be referred to as an "HD" map (as opposed to a conventional "SD" map that contains road centerlines but not lane centerlines). For autonomous driving (AD) purposes, the additional information contained in HD maps and at least lane markings are generally desired. However, the use of these HD maps is not limited to AD applications, and these maps may also find suitable application in any other application where it is desired to provide an improved and more accurate representation of the road contour, including (but not limited to) various advanced driver assistance system (ADAS) applications. Digital map data may also be used in numerous other map-aware or geospatial applications that are not necessarily related to travel, such as applications that require knowledge of location, such as weather applications.Thus, an HD map may also contain data representative of any other features that may be suitable and desirable for inclusion in such a map.While various embodiments will now be described with respect to HD maps, it will be appreciated that the techniques described herein may also be applicable to SD maps.

[0109] Automated vehicles rely heavily on external data, such as sensor information and HD maps. If the integrity or authenticity of this data is compromised, the automated driving function will use faulty data to manipulate the vehicle, which can lead to dangerous driving. The safety goal of the automated driving mission of the vehicle is to keep the risk of personal injury or damage to human health below an acceptable level. Therefore, it is desirable to ensure the functional safety of such map data before it is used.

[0110] In this embodiment, the HD map data comprises a plurality of layers and each layer comprises a plurality of tiles. A tile is associated with a rectangular area of ​​geospatial space. The entire map and individual map tiles each have a 'version' and the map comprises a consistent set of layers and tiles. A tile may be part of several versions of a map, i.e., a tile of a particular version may be associated with multiple map versions. The map data may thus be divided into several layers to group the data according to the type of data, so that the client can selectively download the data that is relevant for its purpose. An example of this is shown in FIG. Figure 2 , which shows a map 30 divided into multiple levels. In particular, the map includes: a base level 50, which includes basic road and lane geometry; and a series of higher levels, which store different types of data associated with the road network. Then, each layer is represented as a plurality of image blocks. Figure 3 Thus, it is shown how data is organized within a digital map. In particular, a digital map 30 consists of a plurality of map layers 32, each of which in turn consists of a plurality of map tiles 34. The digital map 30 is associated with a map version 31, and the map tiles 34 are associated with tile versions 35. The current map version 31 thus includes a set of the most recent map tile versions 35. The map and tile version information is preferably transmitted as metadata for the tile.

[0111] like Figure 4As depicted in , the present embodiment partitions the map into two types of layers, namely, an object layer and an attribute layer. The object layer contains geospatial objects having associated geometry and frequently changing attributes. Objects may have associations with other objects in the same layer or another layer. The attribute layer contains attributes associated with geospatial objects present in another layer. It is generally expected that the attributes present in the attribute layer change more frequently than the objects with which they are associated. For example, in the present embodiment, the map includes a base layer called the HD road layer. The HD road layer is a directed graph comprising arcs and nodes. Each arc has two associated nodes, namely, one node for connection with the incoming arc and one node for connection with the outgoing arc. There are two types of HD road arcs, namely, lane groups and node regions. A lane group consists of one or more lanes having geometry and attributes. A node region includes geometry, legal trajectories, and attributes. The high-level composition of the data structure for the road layer 50 is described in . Figure 5 Depicted in.

[0112] The road layer 50 is in turn composed of a plurality of HD road image blocks. That is, the HD road layer is divided into a plurality of road image blocks, each of which contains arc and node data for the area of ​​the map represented by the image block. The data structure for the image blocks 60 in the road layer is shown in Figure 6 In particular, for each road arc 61 and node 62 that falls within the region of the map covered by the image tile, the security data is stored with the associated arc / node data in a suitable hash. In other words, object level authentication is provided.

[0113] Figure 7 An example of an image block data structure 700 that can be generated and transmitted in the present embodiment is shown in more detail. The image block data structure 700 includes an image block header 701, image block data 702, and an image block signature 703. When the image block data structure 700 is transmitted to a client application, the image block header 701 can be read in a conventional manner to identify the image block in question. For example, the image block header 701 can include information such as an image block id, layer id, layer format, image block version, etc. Then, the image block data 702 can be appropriately extracted. In the present embodiment, the image block data structure 700 is digitally signed with an image block signature 703, thereby allowing the authenticity of the image block data structure 700 to be verified.

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

[0115] For each road object 704, a set of associated functional safety data (ie, safety data) 705 is also included in the image block data structure 700. Figure 7 In the example shown in , the image block data 702 comprises an ordered list of object data 704 and associated security data 705. However, this need not be the case and the data may of course be arranged in any suitable way.

[0116] In this embodiment, the safety data 705 is a hash value extended over the map object id and the map object data. This embodiment uses a secure hash function because it is relatively insensitive to any failure cause or failure mode being protected. However, the functional safety data can be any Error detection code (minimum distance code, hash code, checksum code, parity code, cyclic redundancy check code) or any Error Correction Code (Block codes, convolutional codes, Hamming codes, Viterbi codes).

[0117] In addition, the HD map may include other layers, such as an HD speed limit layer, an HD traffic sign layer, and the like. The HD speed limit layer consists of a set of speed limits associated with lane extensions. The 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 set of traffic signs with geometric shapes and attributes. Traffic signs may be associated with objects in the HD road layer. However, other arrangements of layers will certainly be feasible and in general the HD map may include additional or fewer layers as desired.

[0118] According to the present invention, lane groups, junction areas and nodes (i.e., connections) are preferably stored in a single image block, even if they actually cross the geospatial boundaries of the image blocks. In addition to the advantage of not having to cut and splice (with the potential loss of data quality), the image blocks are still highly independent and the integrity of these meaningful entities can be provided in the data structure of the image blocks to which they belong, as will be further explained below. In an embodiment, this is accomplished by copying the object data for the two (or all) image blocks on which the associated object is extended and storing the object data for the two image blocks separately. However, it is also possible to store the object data in only one of the image blocks, whereupon the other image blocks contain appropriate references (e.g., pointers) to the image blocks in which the data is stored. This method is Figure 8 8, where a road element 80 extending from a first image block 81 into a second image block 82 is stored only in the first image block 81. Then, a suitable delimiting box 83 representing the location of the road element 80 is stored in the second image block 82 together with a suitable reference (pointer) to the first image block 81 pointing to the associated object data of the element 80.

[0119] Fig. 9 An example of a map generation system according to an embodiment is shown. As shown, map source data is obtained from a plurality of sources 26, and then, the map source data is sorted into corresponding levels and image tiles within the levels by a suitable map compiler 12. The map image tiles can then be appropriately distributed to vehicles requiring map data by an image tile data service 18.

[0120] Fig.10 A cloud-based map delivery system is schematically shown in which map data is delivered from the cloud to a vehicle running one or more map-based applications according to an embodiment. Fig.10 The system consists of generating maps in the cloud, delivering map image tiles from the cloud to the vehicle, and distributing the in-vehicle maps to the map application, similar to the above description of Figure 1 However, in Fig.10 In the example, the map image block compiler 12 now includes a map function safety circuit 1210, which is used to add safety data for objects to the map image block data structure, that is, as described above in Figure 7 The HD functional safety module 1210 extends the functionality of the tile map compiler for protecting the integrity of map objects contained in the map tile. Of course, there are a wide range of possible implementations for generating safety data and associating it with object data.

[0121] In addition, Fig.10In the present invention, the 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 requirements and safety requirements under QM (B), while the client front end implements safety requirements under ASIL-BASIL-B (B). The present invention treats the client front end 92 as small and simple by creating the ability to verify the integrity of the HD map data at the entity level that is meaningful to the HD map application (i.e., currently only lane groups, node areas and their associated entities with attributes like speed limits).

[0122] Client front end 92 Fig.11 304, and includes four components, namely, 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 accordance with the required procedures for ISO 26262 ASIL-B ASIL-B. The library is associated with other software and executable parts deployed on a process provided by the ASIL-B compliant ECU platform operating system 105. The client front end is initialized, controlled, and monitored via an interface provided by its controller component 304. The controller 304 interacts with other client front end embedded components, but the interfaces for those interactions are not described in detail. Fig.11 Depicted in.

[0123] The client interface adapter 301 provides the 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 area 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.

[0124] The HD Map Verifier 303 is an integral part of achieving the required functional safety. All object level safety mechanisms are based on hashing. A SHA-256 hash truncated to 64 bits is used because 64 bits is an acceptably small size, and 2 -64 (=5.42*10 -20 ) with the same low safety mechanism failure rate. The client front end 92 checks the integrity and verification of the object data. The client front end 92 may also check the integrity of the latest map version or perform any other desired safety checks.

[0125] Client backend 91 is still there Fig.11206, and includes six components, namely, HD Map RPC Service Stub Area 201, Client Library 202, Persistent Cache 203, Image Block Validator 204, HTTPS Client 205, and Controller 206. The Client Backend 91 is a software library developed using standard Quality Management (QM) defined procedures. The library is associated with other software and executable parts deployed on a process provided by the ASIL-B compliant ECU Platform Operating System 105. The Client Backend is initialized, controlled, and monitored via an interface provided by its Controller Component 206. The Controller interacts with other Client Backend embedded components, but the interfaces for those interactions are not described in detail. Fig.11 Depicted in.

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

[0127] In case of a validation problem, an error is reported to the tile data service and, if applicable, to the client front end 92 via the response to the start service request. The HD Map RPC Client Stub area 102 in the client front end also contains a timeout mechanism. This timeout mechanism triggers a timeout error to be returned if the client back end 91 does not respond to an API call within a specified timeout (passed as an API call parameter).

[0128] The client library 202 stores the image block data and image block metadata in a persistent cache 203 so that it is readily available for later use. Before using data retrieved from the persistent image block cache 203, its integrity is verified by the image block validator 204. In the event of a verification problem, the affected data is purged from the cache and retrieved from the cloud service more recently. The concept of the persistent image block cache 203 consists of Fig.12. The persistent tile cache can be considered to consist of two caches, namely the tile data cache 401 and the tile metadata cache 402. The cache contains a set of cache records, namely the tile data cache record and the tile metadata cache record. Since tiles of a particular tile version may exist in several maps, each with its own unique map version, the 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 that they share. The tile metadata cache record contains metadata calculated by the cloud service on the entire record except for the metadata signature. The tile metadata hash is a 64-bit truncated SHA-256 hash and is used by the client front end to verify the tile metadata.

[0129] The client library 202 interacts with the cloud services 14, 18 via an HTTPS client 205. The HTTPS client 205, for example, authenticates the image block data service 18 and the image block metadata service 14. For example, the client backend 91 can interact with the cloud service via TLS. All messages transmitted between the TLS server and the TLS client are encrypted and remain private even if intercepted. TLS provides message integrity by calculating message digests. Certificate chain-based certificate verification enables the TLS client (i.e., the client backend 91) to authenticate the TLS server (i.e., the map data server and the map metadata server). In order to retrieve the image block, the HTTPS client first retrieves the image block metadata from the image block metadata service 14. This metadata contains the URI of the associated image block, which is used to retrieve the image block from the image block data service 18 if the image block does not yet exist in the persistent image block cache 203.

[0130] Map image tiles and map image tile metadata are stored in image tile data cache records and image tile metadata cache records, respectively. The cache records are digitally signed by the cloud service and verified by the image tile verifier. Thereby, all contents of the persistent image tile cache are digitally signed. Digital signature creation and verification rely on asymmetric cryptography using private encryption keys in the cloud and asymmetric cryptography using associated public decryption keys in the vehicle. After successful verification, the integrity and authenticity of both the image tile data and the image tile metadata are guaranteed.

[0131] The ASIL-B safety mechanisms of the client front end verify the integrity of the HD map data provided by the client to the HD map application. These safety mechanisms operate at the level of arcs (i.e., lane groups and node areas), arc-associated attributes, and nodes. The client back end does not need to be developed at the ASIL-B level, as this level is guaranteed by the client front end. Therefore, the client back end can be developed according to, for example, ISO 26262:2018 QM.

[0132] Both the client front end 92 and the back end 91 can be deployed on the same ECU platform and interact with the underlying ECU platform providing IPC by means of RPC. This allows relying on the secure IPC provided by the ECU platform OS, i.e. avoiding the secure communication protocol stack for inter-processor communication. For example, both the client front end and the client back end may include C++ libraries associated with other code, which are present in associated executables. These executables are deployed on the same ECU platform and interact with the underlying ECU platform providing IPC by means of RPC. In that case, full independence of the QM part (client back end) and the ASIL-B (B) part (client front end) can be achieved by deploying them on separate processors provided by the underlying ASIL-B compliant ECU platform operating system. The RPC-based interaction between the front end and the back end relies on a secure IPC mechanism, which is also provided by the ECU platform compliant with ASIL-B. However, this need not be the case and can be on different ECU platforms.

[0133] Thus, the present embodiment relates to an implementation of an extended map client for an autonomous vehicle application with enhanced fault tolerance. Specifically, instead of applying resilience techniques to the entire map client implementation, an extended map client is provided that includes a map client backend 91 and a map client frontend 92, wherein (only) the map client frontend 92 is designed with functional safety enhancement techniques. A detailed description of the overall operation of the system according to the present embodiment will now be provided. However, other arrangements will certainly be feasible.

[0134] As described above, the map client front end 92 has an interface for docking with a map application (or multiple map applications) and docking with the map client back end 91. The HD map application docks with the map client front end 91 using a fault-tolerant map client service interface, which includes a map client service interface extended with a service interface for fault detection, fault reporting, and fault diagnosis.

[0135] The map client front end 92 therefore provides fault monitoring and it reports any detected faults to the HD map application using a fault-tolerant map client service interface. The purpose of the map client front end is to detect faults in the map client by verifying the integrity of the data it provides. When 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.

[0136] In this embodiment, the map client front end 92 uses functional safety data associated with the 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 the HD road arcs and HD road nodes (map objects) and then generates 'functional safety data' on these compiled data structures (map objects).

[0137] The map client backend 91 receives, validates and caches the image tile data and HD road object data. However, this 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 the same as the data generated in the map server infrastructure.

[0138] The map client front end 92 receives the functional safety data and the HD road object data. If the functional safety data does not correspond to the HD road object data, this indicates that a fault has existed in the map client providing the data. After detecting a fault in the data received from the map client, the map client front end blocks the data and reports the fault to the HD map application requesting the data. The HD map application can use the fault report to trigger an appropriate response. Thus, the map client front end protects the HD map application from faults in the map client module and from faults in the communication path from the map server to the map client front end.

[0139] The fault detection functionality of the map client front end is very small compared to the set of functions of the map client back end. This means that it is suitable for implementation using functional safety design techniques. The functional safety implementation of the map client front end detects and reports all faults of the map client and, due to its functional safety design implementation, is also fault-tolerant in case faults occur in the map client front end implementation itself. The combination of a map client and a client front end is called an extended map client. The extended 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 extended map client provides compliance with functional safety requirements. It uses substantially few resources to achieve this, compared to the functional safety implementation of the map client alone.

[0140] The extended map client provides functional safety map client services for HD map applications, with only a moderate increase in resources (hardware, software, storage, energy, development, testing, maintenance).

[0141] Another benefit of partitioning the map client 22 in the manner described above is that the client front end 92 helps protect the map application from being affected by enhancements implemented in the client back end 91. Variant map client implementations can use normal development practices to improve fault tolerance 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. Since the functional safety compliance is determined by the map client front end implementation, any changes to the map client will not affect the functional safety compliance of the extended map client.

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

[0143] The HTTPS client circuit 205 of the map client backend 91 obtains the data structure image block. The client library circuit 202 of the map client backend 91 first sends the image block to the image block verification circuit 204 of the map client backend 91. The image block verification circuit 204 verifies the authenticity and integrity of the received image block data structure 700 using the image block signature 703. After the image block verification, the client library circuit 202 sends the image block to the persistent image block cache 203 to store the image block data 702.

[0144] 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 request may be a request for an HD road object based on a specific HD road object id or a specific location. The result may be that the requested HD road object does not exist, or that it returns one or more HD road objects from the persistent image block 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 is returned (i.e., tuple: HD road object ID, HD road data, functional safety data). In this embodiment, the map client front end 92 forwards requests from the HD map application and checks the returned HD map object to detect faults in the map client backend 91. The map client front end 92 uses the safety data 705 to check the HD map object data 704.

[0145] Since the map client backend 91 is not involved in any way in the creation or processing of the security data 705 , functional failures of the map client backend 91 can be reliably detected in the map client front end 92 .

[0146] The system described above thus allows map data to be delivered to a vehicle. In particular, the present embodiment ensures that HD map data is securely delivered to the vehicle by verifying the integrity and authenticity of at least the desired HD road-level map data prior to subsequent in-vehicle distribution. (HD map data 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).

[0147] For example, when accepting a request for HD map data, the client should provide the HD map data as specified in the request (i.e., correct data) or return an integrity error. When accepting a request for HD map data, the client should provide the requested HD map data within a specified timeout or return a timeout error immediately after the timeout. Specifically, when accepting a request for HD map data, the client backend should then provide the client frontend HD map data, which is equal to the HD map data retrieved from the cloud service (e.g., after checking the authenticity and integrity of the data at the image block level) and the associated hash value 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 once the HD map data has been verified, the client frontend can provide the requested HD map data to a map-based application. If the HD map data cannot be verified, the client frontend may issue another request for the data, and if, for example, the verified HD map data is not provided within the specified timeout, an integrity error is issued.

[0148] Map metadata is transmitted separately from the map data and is also protected by a hash. That is, each lane group and node area has its own associated metadata hash. The metadata contains version and format information.

[0149] Another variant map data distribution system is Fig.13 . This embodiment utilizes the method described above as an in-vehicle HD map distribution system and is an extension of what was described above. Here, a single client backend 91 services multiple client frontends 92A, 92B distributed in the vehicle by means of remote procedure calls (RPC). In the vehicle, RPC is typically implemented on top of TCP / IP via Ethernet. Relying on secure in-vehicle network communications, the system provides end-to-end (cloud service to in-vehicle HD map application) of HD map data consumed by HD map applications.

[0150] Note that this system will transmit more data via the vehicle network than, for example, ADASIS V3 will transmit. 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 for fine-grained selection of the data to be transmitted. However, Ethernet has a much higher bandwidth than CAN, making it less important to optimize the minimum amount of data to be transmitted. The client presented above provides an API to perform fine-grained selection during data transmission and verify that the execution is complete.

[0151] Fig.14 Another example is shown where a single map front end 92 is served by multiple map clients (client back ends 91A, 91B).

[0152] The present embodiment thus provides an HD map delivery system that is secure and includes verification of the integrity / authenticity of HD map data at the level of meaningful entities (e.g., lane groups and node regions) before the HD map data is delivered to the application. Furthermore, the desired functional safety is achieved in an efficient manner by splitting the map client into a front-end / back-end that can be implemented at different functional safety levels.

[0153] The foregoing detailed description is presented for the purpose of illustration and description. It is not intended to be exhaustive or to limit the technology described herein to the precise form disclosed. In view of the above teachings, many modifications and variations are feasible. The described embodiments are selected to best explain the principles of the technology described herein and its practical application, thereby enabling other technical personnel in the field to best utilize the technology described herein in various embodiments, and with various modifications suitable for the intended specific use. Therefore, the features disclosed in this specification, drawings and / or claims may be materials for the implementation of various embodiments performed alone or in various combinations thereof. In addition, although the present invention has been described with reference to various embodiments, it will be understood by those skilled in the art that various changes can be made in form and detail without departing from the scope of the invention as stated in the appended claims.

Claims

1. A method of validating map data transmitted from a remote server to one or more map-based applications executed on an electronic control unit of a vehicle traversing a navigable network covered by a digital map, wherein the digital map is represented as a set of a plurality of map image tiles, each map image tile representing a specific geographical area containing a portion of the navigable network, the method comprising: generating at the server a data structure for a map image tile, wherein the data structure comprises object data indicative of a set of one or more objects that are at least partially within the geographical area covered by the map image tile and / or within the geographical area covered by another one or more of the map image tiles representing the digital map, wherein for at least one object in the set of one or more objects whose object data is included in the map image tile data structure, associated object-level security data is included in the map image tile data structure together with the object data for the at least one object, the object-level security data being capable of being used to verify the integrity of its associated object data; and transmitting the data structure for the map image tile containing the object data and associated object-level safety data from the server to a client application executing on one or more processing units of the vehicle, The map image block data structure further has a digital signature to verify the authenticity and / or integrity of the map image block data structure, and the digital signature for the map image block data structure is applied by the server.

2. The method according to claim 1, further comprising The client application unpacks the image block data to extract object data indicative of one or more objects whose data is stored in the image block data structure; and The client application verifies the integrity of the extracted object data using the associated object-level security data.

3. A method of operating a client application executing onboard a vehicle traversing a navigable network in a geographic area covered by a digital map, wherein the digital map is represented as a set of a plurality of map image tiles, each image tile representing a particular geographic area comprising a portion of the navigable network, and wherein each map image tile has an associated map image tile data structure comprising: object data indicative of a set of one or more objects at least partially within the geographical area covered by the map image tile and / or within the geographical area covered by another one or more of the map image tiles representing the digital map; and object level security data for verifying the integrity of the object data associated with at least one object whose object data is stored in the map image tile data structure, wherein the map image block data structure further has a digital signature to verify the authenticity and / or integrity of the map image block data structure, the digital signature for the map image block data structure being applied by a server, and the map image block data structure being transmitted from the server to the client application, The method comprises: receiving, at the client application, from one or more map-based applications, a request for map data associated with one or more features of the navigable network; Obtaining, by the client application, object data associated with the one or more features from a corresponding map image tile data structure; obtaining object-level security data associated with said obtained object data from said corresponding map image tile data structure; and The client application verifies the integrity of the object data using the object-level security data and, when the data is verified, passes the object data to the one or more map-based applications.

4. A method according to any one of claims 1, 2 or 3, wherein the associated object-level security data for an object includes at least a hash value calculated using the object data for the object, and wherein verifying the integrity of the object data includes the client application recalculating the hash and comparing the recalculated hash value with the hash value for the object contained in the image block data structure.

5. A method according to any one of claims 1, 2 or 3, wherein the client application includes a first application and a second application, the first application communicates with the one or more map-based applications and the second application, and the second application communicates with the server.

6. A method according to claim 5, wherein in response to a request from the one or more map-based applications for information about a feature within the navigable network covered by the digital map, the first application requests object data associated with the feature from the second application, wherein the second application then obtains the relevant object data and its associated object-level security data and provides the object data and the associated object-level security data to the first application, wherein the first application verifies the integrity of the object data using the object-level security data.

7. The method of claim 6, wherein when the first application verifies the integrity of the object data, then the object data is provided from the first application to the one or more map-based applications.

8. The method of claim 7, wherein when the verification of the object data fails, the first application generates an integrity error message and / or generates another request for the object data.

9. A method according to claim 5, wherein the second application includes a map image tile cache storing data obtained from the server for multiple map image tiles, and wherein the second application is capable of obtaining the object data by first checking whether the object data exists in the map image tile cache, wherein when the object data related to the request exists in the map image tile cache, the second application reads the object data from the map image tile cache, and when the object data does not exist in the map image tile cache, the second application issues a request for the object data to the server.

10. A method according to claim 9, wherein the second application verifies the authenticity and / or integrity of the map image tile data structure received from the server using an associated digital signature before adding the data obtained from the server to the map image tile cache.

11. The method of claim 5, wherein the second application is developed according to a lower functional safety standard than the first application.

12. The method of claim 11, wherein the first application is developed according to at least the ISO 26262:2018 ASIL-B functional safety standard.

13. The method of claim 5, wherein the first application is implemented redundantly.

14. The method of claim 5, wherein the first application executes on the same processing platform as the one or more map-based applications.

15. The method of claim 14, wherein the processing platform comprises an electronic control unit of the vehicle.

16. A method according to claim 3 for operating a client application running on one or more processing units of a vehicle traversing a navigable network in a geographic area to provide digital map data from at least one remote server to one or more map-based applications running on an electronic control unit of the vehicle, wherein: The client application includes a first application and a second application, the first application communicates with the one or more map-based applications and the second application, and the second application communicates with the at least one remote server; The at least one remote server is capable of accessing: (i) a map tile data storage area storing a plurality of map tiles, each map tile representing the navigable network in a portion of the geographic area as a plurality of arcs connected by nodes; and (ii) a map tile metadata data storage area storing metadata for each of the map tiles in the map tile data storage area, wherein each arc and node of a tile has object data associated therewith and object-level security data in the form of a hash value, the hash value being calculated at the server based on at least the object data for the corresponding arc or node, and the tile metadata for the tile containing the object data for the corresponding arc or node; and the second application comprises: (i) a map image tile cache storing a plurality of map image tiles obtained from the at least one remote server; and (ii) a map image tile metadata cache storing the metadata for each of the map image tiles obtained from the at least one remote server in the map image tile cache, the method comprising: receiving, by the first application, a request from the one or more map-based applications for digital map data regarding features of the navigable network; requesting, by the first application program, from the second application program, the object data and the hash value for the at least one arc or node associated with the requested digital map data; obtaining, by the second application, the requested object data and hash value from the map tile cache or, if the required tile is not stored in the map tile cache, from the map tile data store and providing them to the first application; requesting, by the first application to the second application, the metadata for the map image tile regarding the at least one arc or node associated with the requested digital map data; obtaining, by the second application, the requested tile metadata from the map tile metadata cache or, if the required tile metadata is not stored in the map tile metadata cache, from the map tile metadata data store 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 image block metadata; comparing, by the first application, the new hash value with the received hash value; and The requested digital map data or an integrity error message is provided by the first application to the one or more map based applications based on the comparison.

17. The method of claim 16, wherein the second application is developed according to a lower functional safety standard than the first application.

18. The method of claim 17, wherein the first application is developed according to at least the ISO 26262:2018 ASIL-B functional safety standard. The method of claim 16 , wherein the first application is implemented redundantly.

20. The method of claim 16, wherein the first application executes on a same processing platform as the one or more map-based applications.

21. The method of claim 20, wherein the processing platform comprises an electronic control unit of the vehicle.

22. A method according to any one of claims 1, 3 or 16, wherein the map image block represents the navigable network in the portion of the geographic area as a plurality of arcs connected by nodes, wherein each arc and node of the image block has object data and object-level security data associated therewith.

23. A method according to any one of claims 1, 3 or 16, wherein the one or more map-based applications are autonomous driving applications or wherein the one or more map-based applications are vehicle vision providers, which in turn provide map data to the autonomous driving applications, and wherein when verification of the requested object data based on the associated object-level safety data fails, the autonomous driving application operates the vehicle in a safe mode and / or brings the vehicle to a safe stop.

24. A server system communicatively coupled to an electronic control unit of a vehicle and configured to perform the method of claim 1.

25. An electronic control unit of a vehicle, executing one or more client applications, the one or more client applications being configured to execute the method of claim 3.

Images