METHOD AND DEVICES FOR PROVIDING DATA FOR A DRIVER ASSISTANCE SYSTEM OF A MOTOR VEHICLE

Description

[0001] The present invention relates generally to methods and devices for providing data, in particular map-based or georeferenced data, for a driver assistance system of a motor vehicle and in particular for providing data for an electronic horizon of a motor vehicle.

[0002] A navigation system can also serve as a sensor for other advanced driver assistance systems (ADAS) in a vehicle, improving or expanding their functionality. ADAS are electronic add-ons in motor vehicles designed to support the driver in specific driving situations. Safety aspects are often paramount, but so is increasing driving comfort. Another important aspect is improved fuel economy. To support the ADAS, location-based information can be transmitted from a navigation system or a head unit (hereinafter also referred to as the main unit) of an infotainment system to one or more other control units for driver assistance functions in the vehicle. The head unit essentially acts as a server, while the individual control units or ADAS act as clients.The transmitted location-based information is often referred to in technical language as the electronic horizon. Some examples of driver assistance systems are described in US 2009 / 299625 A1, DE 10 2010 034140 A1, and DE 10 2011 083399 A1.

[0003] Systems for generating an electronic horizon based on digital road maps are known. These systems use various protocols for distributing information within the vehicle network, such as ADASIS v2, ADASIS v3, and BMW ADAS 2.1. Typically, the CAN bus (CAN = Controller Area Network) is used as the communication channel in this context. The protocols are based on an extracted navigation graph in the form of one or more paths (ADASIS v2 and v3) or a tree (ADAS 2.1). A navigation graph serves as a reference system for the corresponding attribution and thus information distribution. Attributes of a digital road map can be understood as features and / or properties of these features.Features are appropriately considered possibilities for local characteristics of real roads or other objects in the digital road map, such as road classifications, speed limits, or traffic signs. These features have location-dependent specific properties.

[0004] The decision as to which elements (based on topological links or segments) from a digital navigation map are included in the electronic horizon is typically made by the head unit. Using various algorithms, it can determine the most probable route (MPP) and explore the map in that direction. Depending on the strategy employed, it can then explore corresponding cross streets. In other words, the electronic horizon can contain information about the road network ahead (topology), with only those roads relevant that are reachable from the vehicle's current position and that are likely to actually be traveled.

[0005] The length of the corresponding electronic horizon is influenced by various factors, such as the density of information in the respective area or the encoding used in the format. Typically, the predictive length of the electronic horizon is approximately 500 m to 6 km, depending on the requirements of the driver assistance systems utilizing the electronic horizon.

[0006] Since different driver assistance functions in the vehicle require different predictive ranges, the electronic horizon can have different configurations. For example, a 2D configuration, which includes not only the most probable route but also its corresponding branches, or a 1D prediction, which only follows the most probable route or, more generally, the course of a planned route. This allows different driver assistance functions to be supplied with varying levels of information.

[0007] The aforementioned currently available driver assistance and ADAS protocols for transmitting the electronic horizon are already reaching their transmission limits. The extent or predictive length of the predictive range is limited by the density of existing location-based attributes (such as speed limits, gradients, curves, etc.). New attributes / features cannot be added because the messages or protocols generally cannot be extended with new fields. Transmitting highly accurate map data for future driver assistance systems, such as a precise lane model including the underlying geometry, is not possible with current CAN-based ADAS protocols. Increasing the bandwidth by changing the underlying layer, e.g.,Switching from CAN to Ethernet only partially addresses these challenges, as the encoding formats used in ADAS protocols are not designed for this type of information. The ADASIS v3 protocol, for example, pursues this approach. However, it too relies on individual paths as segments of the navigation map.

[0008] Another disadvantage of currently known ADAS protocols and implementations is that the head unit, as the source of navigation-based information, calculates the most probable route. This means that all connected driver assistance functions must operate using this most probable route. However, different driver assistance functions may prefer different variations of the most probable route. For example, one driver assistance function might always want to follow the road's course and always try to ascend to the next higher road class (e.g., changing from a country road to a highway), while other driver assistance functions prefer driving straight ahead. This can lead to a situation where information required by the driver assistance function is missing from the electronic horizon, as it has already been filtered out by the head unit.

[0009] Due to the rigidly structured protocols of current implementations of the electronic horizon, all necessary information must be defined and specified as attributes at the time of the protocol's design. Subsequent expansion with additional attributes typically involves new development work and corresponding costs. As a result, current implementations of the electronic horizon are very inflexible and cannot flexibly adapt to the new requirements of future driver assistance functions, such as highly automated driving.

[0010] The connectivity between current and, especially, future vehicles and corresponding backend services is constantly increasing. This allows map information to be updated ever faster, from updating the map's topology to highly dynamic updates of traffic conditions and the currently displayed values ​​of variable message signs. This highly dynamic data cannot be transmitted using current versions of the vehicle's electronic horizon.

[0011] The various driver assistance functions in the vehicle have different requirements for the information displayed from the digital map. Some driver assistance functions require very detailed information both at the current position and along the entire road network (topology) in front of the vehicle. Other driver assistance functions only need individual attributes about the topology and / or the current vehicle position (e.g., the current speed limit). The various available versions of the electronic horizon cannot currently adapt flexibly to these requirements. All functions must agree on uniform interfaces and thus cope with sometimes too much or too little information.

[0012] Therefore, it can be considered an object of the present invention to further develop and improve the prior art relating to the provision of map-based data in a motor vehicle.

[0013] This is achieved through methods and devices with the features of the independent patent claims. Advantageous embodiments and further developments are the subject of the dependent claims.

[0014] According to a first aspect, embodiments of the present invention provide a method for supplying data, in particular map-based or georeferenced data, to a driver assistance system of a motor vehicle. The method comprises the direct or indirect transmission of position data concerning the current or future position of the motor vehicle, e.g., from an internal or external positioning and / or navigation unit, to the driver assistance system. Only when the driver assistance system requires additional information about the position data does it request this additional information from an internal or external server. Thus, requests are demand-driven – no need, no request; if needed, a request. In response to the request, the internal or external server transmits the additional information directly or indirectly to the driver assistance system.

[0015] The proposal therefore calls for providing navigation data at different levels. Position data (possibly including the current position) is regularly transmitted to the driver assistance system by the positioning or navigation unit as a kind of basic information. Transmitting the position data along with the current vehicle position can thus be considered a fundamental or necessary transmission. Only when needed does the driver assistance system or its associated control unit request further data related to the position data or the current vehicle position, such as attributes of the current vehicle position or additional topological data. This additional information can also include georeferenced volatile data: for example, weather, traffic flow, etc.Examples of implementation can be advantageously used, for instance, for the scalable provision of map-based data for an electronic horizon.

[0016] The navigation unit can be a permanently installed infotainment or navigation head unit in the vehicle. However, it is also conceivable that a positioning or navigation system not permanently installed in the vehicle, such as a smartphone, can be used as the navigation unit. The navigation unit can therefore be designed to provide at least current and / or future position data. It can also be a simple position transmitter without further functionalities. Optionally, the navigation unit can also have more complex functions, such as route calculation and / or providing additional map-based attributes. The server can also be the infotainment or navigation head unit (main unit) installed in the vehicle. However, external servers (e.g., the internet) are also conceivable.

[0017] In some examples, position data can refer to the coordinates of a vehicle's current position. However, position data can also include future position data or coordinates along a planned route or a path that is considered likely to be followed. A current or future vehicle position (Current Car Position, CCP) can be described with varying levels of detail, such as the actual position in WGS84 coordinates (World Geodetic System 1984), i.e., a raw position based on GPS and vehicle odometry. Another possibility is, for example, specifying a map section (e.g., map tile, tile ID) in which the current vehicle position is located. Additionally, a topological element of this map section, such as a node or edge (link ID), on which the vehicle is currently located can be specified.To identify the current vehicle position within the map section even more precisely, an offset value can also be specified, indicating where the vehicle is currently located on the topological element. Other formats are of course also possible, depending on their compatibility with the receiving control unit.

[0018] The position data represents the basic information for the on-demand data provision presented here, which is provided to the driver assistance system by the positioning or navigation unit at a minimum. It could also be understood as a kind of base layer of the proposed protocol. The additional information, on the other hand, can be understood as an on-demand supplementary layer of the protocol.

[0019] In some implementations, the transmission of position data can occur periodically or cyclically, for example, after the driver assistance system has registered with the positioning or navigation unit. Instead of classic push notifications, the proposed ADAS protocol can distinguish between the following variants: cyclical transmission of the current position data and on-demand request / response regarding additional (map-based) information. Cyclical transmission can be used to cyclically provide the recipient with relevant data requested by the recipient. In the case of the proposed ADAS protocol, this can include only the transmission of the current position. Optionally, a selection of map attributes applicable to the current position can also be transmitted cyclically.Attributes at the current position can be describable using configurable data formats, known as Data Definitions. These include, for example, the number of lanes, road classification, road name, speed limit, gradient values, etc. In addition to the regular transmission of position data, the on-demand request for additional information can, in some implementations, include requesting map information associated with the position data from a digital road map. In other words, the driver assistance system client also has the option of directly requesting map information via a request / response interface. This map information can include location-based attributes associated with the position data and / or location-based topological information, which is not transmitted on a regular basis but rather on request from the server (e.g., the system).from the main unit) to the driver assistance system. Attributes of a digital road map are understood here as features and / or properties of these features. Features are possibilities appropriately considered in the digital road map for local characteristics of real roads, such as road classes, traffic signs, speed limits, curve radii, road surface condition, etc. These features have location-dependent specific properties. Topological information or data, on the other hand, refers to a road network structure and can, for example, describe turning restrictions at intersections. Topological information can be understood, for example, as nodes and edges in a road network graph, i.e., a connection between two decision points (e.g., intersections) in the graph.

[0020] The topology of the road network forms the basis of the map information. This topology can be stored in digital road maps as a graph. Any information can then be stored as attributes on the elements (edges and nodes) of this graph. In some implementations of the proposed ADAS protocol, the topology can be decoupled from the attributes. This means that for map queries that extend beyond the current position, the driver assistance system client can query the topology using various methods and then retrieve the required information as attributes for these topology elements.

[0021] In some implementations, the on-demand request for additional information can initially involve requesting topological data associated with the position data. In such cases, transmitting the additional information can include transmitting topological data from map tiles of a digital road map associated with the position data. This allows the driver assistance system to be supplied with topological data related to the position data as needed. Thus, upon request, one or more topological elements (nodes, edges, etc.) can be transmitted to the driver assistance system, depending on requirements. No predefined sets of topological data to be transmitted are provided. The client can either query only the currently driven road segment (in the form of the current link and knowledge of the connected links) or a larger section of the topology.This excerpt can be based on a fixed tile scheme, e.g. the NDS tile scheme at level 13.

[0022] If the client can obtain the topology information, it can query any attributes for any element within this topology. After receiving the topological data, the driver assistance system can, if needed, request additional attributes associated with the topological data from the vehicle's internal or external server. In some implementations, requesting this additional information can also include requesting at least one attribute associated with the topological data. In response to the request, the server can transmit the at least one attribute to the driver assistance system. Here, too, attribute requests are on-demand, meaning that transmission only occurs when the driver assistance system needs or wants the attributes. This allows for efficient and demand-driven use of transmission resources.

[0023] In some embodiments, the demand-driven querying of topological data and / or attributes can also be equivalent to a subscription to the requested topological data and / or attributes from the driver assistance system for the future. In such embodiments, a single query may be sufficient to indicate to the server the need for the respective data, so that the server can transmit this data to the driver assistance system "unsolicited" in the future, e.g., periodically or when attributes change.

[0024] For querying map attributes, some implementations propose a mechanism that allows for a precise early description at the protocol level of how information is transmitted, while permitting the description of the transmitted data at a later time. Using the aforementioned DataDefinitions, it can be specified that any information in the form of primitive data types (such as an integer field) can reside at a topology element or the CCP. The meaning of the data types can be defined via the DataDefinition description. Updated DataDefinitions can be provided to the head unit periodically to accommodate new driver assistance systems. Each DataDefinition can be assigned a unique ID, which can be part of the ADAS protocol.The ID allows the corresponding DataDefinition to be identified and a meaning to be assigned to the primitive data types. According to some embodiments, the transmission of at least one attribute can therefore take place in a data format (DataDefinition) adapted to the attribute. This data format can include a unique identifier for the data format and a description of the data types contained within it.

[0025] In the navigation environment, there is a multitude of data that can change frequently, such as variable message signs or traffic flow. This data is considered volatile or dynamic. In the proposed ADAS protocol, this data can also be encapsulated in DataDefinitions and additionally classified as dynamic data with a corresponding lifetime. In other words, at least one attribute can be a variable attribute. In some implementations, the description of the data types contained in the data format can include an identifier for a variable attribute and its associated validity period.

[0026] In different implementations of the protocol, the variable attributes can then be handled separately. For example, the client can query new data after the expiration of the attribute's lifetime or validity period. In other words, querying at least one attribute can include querying the attribute again after its validity period has expired. Additionally or alternatively, the client can be informed separately if previously queried dynamic data has changed. It can then decide whether to retrieve this data again. In such implementations, the process can therefore include a step of informing the driver assistance system about a changed attribute. If the client does not retrieve this data again, it does not need to be informed about future changes to this data.

[0027] In some implementations, the position data and additional information are transmitted via an internal vehicle bus system. Possible bus systems include fieldbuses such as CAN, FlexRay, or Local Interconnect Network (LIN). Other implementations also allow, or alternatively allow, data transmission via Ethernet or other Local Area Network (LAN) technologies.

[0028] According to another aspect, exemplary embodiments create a system for providing data to a motor vehicle's driver assistance system. The system can include a positioning or navigation unit (e.g., head unit, driver assistance system server) configured to transmit position data concerning the vehicle's location to a driver assistance system (or its associated control unit). The system further includes a driver assistance system (or its associated control unit) configured to receive the position data and, if required, to request additional information from a server, either internal to or external to the vehicle. The server is configured to transmit the requested additional information to the driver assistance system in response to the request.

[0029] According to another aspect, a driver assistance system (or its associated control unit) is provided which is designed to receive position data concerning the position of a motor vehicle from a positioning or navigation unit and to request additional information from the navigation unit or a server, in particular an in-vehicle main unit, only when additional information about the position data is required.

[0030] According to an additional aspect, a server, specifically an in-vehicle main unit, is also provided. The server is configured to transmit position data concerning the location of a motor vehicle to a driver assistance system and, in response to a request from the driver assistance system, to transmit additional information about the position data to the driver assistance system.

[0031] The proposed demand-driven division of the ADAS protocol allows for strong scaling effects: a simple driver assistance function, which only requires information at the current position, only needs to evaluate the current CCP information, while a complex driver assistance function, on the other hand, can query arbitrarily complex information up to highly accurate lane models via the topology and the corresponding DataDefinitions.

[0032] The division into topology and attributes also enables strong scaling effects: the client can decide for itself which detailed information to request and to what extent. Generally, the client can run on a less powerful control unit than the server and therefore have less memory. It can thus tailor its requests based on available memory and the required information content. This allows the client to decide how much information to process and when. With traditional ADAS protocols, this is defined from the outset and cannot be adjusted subsequently. As a result, highly accurate lane models can only be transmitted via traditional ADAS protocols with significant modifications.

[0033] The proposed protocol is dynamic and can adapt to changes because, at the time of its definition (the data format to be transmitted), the specific information to be transferred does not need to be determined. This allows new information to be added during the protocol's lifetime in the form of new DataDefinitions. Existing clients may not be able to interpret this new information, nor will they request it. New clients, however, will be aware of the new DataDefinitions and can process them accordingly.

[0034] The proposed methods allow the protocol to handle dynamic information very efficiently. Traditional protocols do not permit dynamic information because once transmitted, information cannot be modified. This means that all new information would have to be transmitted, whereas the proposed protocol allows individual pieces of information to be retransmitted after the client has been notified of the update.

[0035] Some exemplary embodiments of the present invention are explained in more detail below with reference to the accompanying figures. These show: Fig. 1 a schematic representation of an exemplary system for providing data to a driver assistance system of a motor vehicle; Fig. 2 a sequence of data exchange between a head unit and a driver assistance system; and Fig. 3 an example of a possible transmission between client and server according to an embodiment.

[0036] Various embodiments will now be described in more detail with reference to the accompanying drawings, in which some embodiments are illustrated.

[0037] In the following description of the accompanying figures, which merely show some exemplary embodiments, the same reference numerals can denote identical or comparable components. Furthermore, collective reference numerals can be used for components and objects that appear multiple times in an embodiment or in a drawing, but are described jointly with respect to one or more features. Components or objects described with the same or collective reference numerals can be identical with respect to one, several, or all features, such as their dimensions, but may also differ, unless the description explicitly or implicitly indicates otherwise.

[0038] Although embodiments can be modified and altered in various ways, they are shown in the figures as examples and are described in detail herein. It should be clarified, however, that the intention is not to limit embodiments to the forms disclosed, but rather that they are intended to cover all functional and / or structural modifications, equivalents, and alternatives within the scope of the invention. The same reference numerals throughout the figure description denote identical or similar elements.

[0039] Note that an element described as "connected" or "coupled" to another element may be directly connected or coupled to that element, or there may be intervening elements. Conversely, if an element is described as "directly connected" or "directly coupled" to another element, there are no intervening elements. Other terms used to describe the relationship between elements should be interpreted similarly (e.g., "between" versus "directly between," "adjacent" versus "directly adjacent," etc.).

[0040] The terminology used herein serves only to describe specific embodiments and is not intended to limit the embodiments. As used herein, the singular forms "a," "an," "an," and "the" are intended to include the plural forms unless the context clearly indicates otherwise. Furthermore, it should be clarified that expressions such as "includes," "containing," "has," and / or "showing," as used herein, indicate the presence of the aforementioned features, integers, steps, processes, elements, and / or components, but do not preclude the presence or addition of one or more features, integers, steps, processes, elements, components, and / or groups thereof.

[0041] Fig. 1 shows a schematic representation of an exemplary system 100 for providing data for a driver assistance system of a motor vehicle, in particular for providing data for an electronic horizon.

[0042] System 100 comprises an in-vehicle head unit 110 as a server and several connected driver assistance systems 120-1, 120-2, 120-3, or their associated control units, as clients. The head unit 110 can, for example, be assigned to the vehicle's infotainment system. It can integrate functions from consumer electronics, internet technology, comfort controls, and navigation. The various driver assistance systems 120-1, 120-2, 120-3 can be connected to the head unit 110, for example, via an in-vehicle data bus, such as the CAN bus. In some embodiments, the driver assistance systems 120-1, 120-2, 120-3 can enable at least partially autonomous driving of the vehicle or support the driver.

[0043] The head unit 110 regularly transmits current vehicle position data 130 to the connected driver assistance systems 120-1, 120-2, and 120-3, for example, periodically or cyclically. This vehicle position data represents a minimum level of information transmitted between the head unit 110 and the driver assistance systems 120-1, 120-2, and 120-3. It should be noted that the vehicle position data (current and future) can also originate from another suitable navigation unit, which does not necessarily have to be permanently installed in the vehicle.

[0044] Depending on their functionality, the driver assistance systems 120-1, 120-2, and 120-3 may have varying requirements for additional information beyond the current vehicle position data. This additional information could be map information from a digital road map associated with the position data (i.e., location-based). Therefore, in the exemplary embodiment, the driver assistance systems 120-1, 120-2, and 120-3 are each configured to request the required additional information from the head unit 110 only when needed. In other embodiments, the additional information could also be requested from an external server. This additional information is typically required not only at the vehicle's location but also in its surroundings, e.g.,along a planned route or path that is considered likely to be followed. In addition to position data, information about the planned route or similar details can therefore be crucial for further queries. The corresponding queries are located in . Fig. 1 The driver assistance systems are designated 140-1, 140-2, and 140-3. In response to the respective requests 140-1, 140-2, and 140-3, the head unit 110 transmits the requested additional information 150-1, 150-2, and 150-3 to the respective driver assistance systems 120-1, 120-2, and 120-3. Thus, an on-demand exchange of individually required additional information, such as map-based data, takes place between the driver assistance systems 120-1, 120-2, and 120-3 and the head unit. Each driver assistance system 120-1, 120-2, and 120-3 can therefore be individually supplied with different additional information.

[0045] While the additional information 150-1 required by the first driver assistance system 120-1, in addition to the position data, may relate to one or more map attributes (e.g., the permitted maximum speed) that apply at the current position, the additional information 150-2 required by the second driver assistance system 120-2, in addition to the position data, may include topological data, such as road network elements, related to the position data. The third driver assistance system 120-3, for example, may be interested in both additional topological data and attributes relating to the topological data as additional information 150-3, and thus exhibit the highest individual data requirement. The driver assistance system 120-3 may, for example, implement a more complex driver assistance function with higher data requirements (e.g., adaptive cruise control).

[0046] A basic sequence of data exchange between head unit 110 and one of the driver assistance systems 120-1, 120-2, 120-3 is shown in the schematic message sequence diagram (MSC) 200 of the Fig. 2 illustrated.

[0047] First, in step 210, position data concerning the current position of the vehicle is transmitted from the head unit 110 to the driver assistance system (DAS) 120. If necessary, in step 220, the driver assistance system (DAS) requests additional information (such as attributes and / or topological data) from the head unit regarding the position data. In step 230, the head unit 110 then sends the requested or required additional information to the driver assistance system (DAS).

[0048] After based on the Fig. 2 The communication between the Head Unit 110 and the driver assistance system (DAS), which was outlined in relatively general terms, will now be explained using the following examples: Fig. 3 A more concrete example of implementation is described. Fig. 3 A possible communication between driver assistance system (ADAS client) 120 and head unit (server) 110 is shown in an embodiment of the proposed protocol.

[0049] Client 120 is cyclically supplied with the current vehicle position via messages 310 after logging into server 110. In the example shown, the current vehicle position is passed to client 120 in the form of a tile ID (TileD), a link ID (Edge ID), and an offset on the link. The tile ID identifies a map section in which the current vehicle position is located. The link ID identifies a topological element within this map section, such as a node or an edge, on which the vehicle is currently located. The offset indicates precisely where on the topological element the vehicle is currently located.

[0050] Based on this basic information 310, client 120 can query additional required topology information, see step 320. In the example shown here, based on the simple position information 310, a topology tile with an example tile ID 0815 is requested from the head unit 110, which is then transmitted to client 120 in a subsequent step 330.

[0051] Depending on the information requirements, client 120 can then query further map attributes needed for topology tile 0815 in step 340, such as the maximum permissible speed for one or more edges (e.g., roads) of the topology tile. For this purpose, client 120 can send a DataD (here: DataD = 4711) to the head unit 110, which describes the desired map attributes or DataDefinition. Using the DataD, the corresponding DataDefinition can be identified and a meaning assigned to primitive data types.

[0052] In a subsequent step 350, the head unit 110 sends the requested attributes to the client 120 in a data format defined by the corresponding DataDefinition, according to DataD = 4711. According to some embodiments, the transmission of at least one attribute can therefore take place in a data format (DataDefinition) adapted to the attribute. The data format can include a unique identification of the data format or the attribute and a description of the data types contained in the data format.

[0053] As shown in the example, the attributes transmitted by the head unit 110 in step 350 can additionally be classified as dynamic data ("isTemporalTile" = yes) and, if applicable, have a corresponding lifetime. In other words, at least one attribute can be a variable or volatile attribute. In some implementations, the description of the data types contained in the data format can therefore include an identifier for a variable attribute and an associated validity period.

[0054] If the requested data includes dynamic data, Client 120 can be notified of any updates to this data. Head Unit 110, in turn, can be informed of the update, for example, via Car2X communication techniques or backend services. In the example shown, in step 360, Head Unit 110 informs Client 120 of a change to attribute 4711, which belongs to topology tile 0815. This allows Client 120 to request the changed attribute data from Head Unit 110 in step 370, if necessary. Finally, Head Unit 110 then sends the requested changed attribute data to Client 120.

[0055] In summary, some implementations distinguish between cyclic basic transmission and additional request / response. Cyclical basic transmission can be used to cyclically provide the recipient with relevant basic data requested by the recipient. In the case of the proposed ADAS protocol, this includes the transmission of the current position and, optionally, a selection of map attributes applicable to the current position. Furthermore, the client has the option of directly requesting map information via the on-demand additional request / response interface. Implementations can thus achieve greater flexibility than previous ADAS concepts.

[0056] The features disclosed in the foregoing description, the following claims and the accompanying figures can be important and implemented individually or in any combination for the realization of an embodiment in its various configurations.

[0057] Although some aspects have been described in connection with a device, it is understood that these aspects also constitute a description of the corresponding process, so that a block or component of a device can also be understood as a corresponding process step or as a feature of a process step. Similarly, aspects described in connection with or as a process step also constitute a description of a corresponding block, detail, or feature of a corresponding device.

[0058] Depending on specific implementation requirements, embodiments of the present invention, or at least parts thereof, can be implemented in hardware or in software. The implementation can be carried out using a digital storage medium, for example, a floppy disk, a DVD, a Blu-ray disc, a CD, a ROM, a PROM, an EPROM, an EEPROM, a FLASH memory, a hard disk, or another magnetic or optical storage medium on which electronically readable control signals are stored. These control signals can interact with, or interact with, a programmable hardware component in such a way that the respective method is carried out.

[0059] A programmable hardware component can be a processor, a computer processor (CPU = Central Processing Unit), a graphics processor (GPU = Graphics Processing Unit), a computer, a computer system, an application-specific integrated circuit (ASIC = Application-Specific Integrated Circuit), an integrated circuit (IC = Integrated Circuit), a system-on-a-chip (SOC = System on Chip), a programmable logic element, or a field-programmable gate array with a microprocessor (FPGA = Field Programmable Gate Array).

[0060] The digital storage medium can therefore be machine-readable or computer-readable. Some embodiments thus include a data carrier containing electronically readable control signals capable of interacting with a programmable computer system or programmable hardware component to execute one of the methods described herein. An embodiment is therefore a data carrier (or a digital storage medium or a computer-readable medium) on which the program for performing one of the methods described herein is recorded.

[0061] In general, embodiments of the present invention can be implemented as a program, firmware, computer program, or computer program product with program code or as data, wherein the program code or data is / are effective in carrying out one of the methods when the program runs on a processor or a programmable hardware component. The program code or data can, for example, also be stored on a machine-readable medium or data carrier. The program code or data can be in the form of, among other things, source code, machine code, bytecode, or other intermediate code.

[0062] A program according to one embodiment can implement one of the methods during its execution, for example, by reading memory locations or writing data to them, thereby potentially triggering switching operations or other processes in transistor structures, amplifier structures, or other electrical, optical, magnetic, or otherwise operating components. Similarly, by reading a memory location, a program can acquire, determine, or measure data, values, sensor values, or other information. Therefore, by reading from one or more memory locations, a program can acquire, determine, or measure quantities, values, measured values, and other information, and by writing to one or more memory locations, it can initiate, trigger, or execute an action, as well as control other devices, machines, and components.

[0063] The embodiments described above merely illustrate the principles of the present invention. It is understood that modifications and variations of the arrangements and details described herein will be obvious to other people skilled in the art. Therefore, it is intended that the invention be limited only by the scope of protection set forth in the following claims and not by the specific details presented herein by way of description and explanation of the embodiments.

Claims

1. Method (200; 300) for providing data for a driver assistance system (120) of a motor vehicle, comprising: transmitting (210; 310) position data (130) relating to a position of the motor vehicle to the driver assistance system (120); only upon demand of the driver assistance system (120) for additional information (150) relating to the position data, requesting (220; 320) the additional information from a server (110); and in response to the demand-driven requesting (220; 230), transmitting (230; 330) the additional information (150) from the server (110) to the driver assistance system (120).

2. Method (200; 300) according to claim 1, wherein the transmitting (210; 310) of the position data is carried out periodically.

3. Method (200; 300) according to claim 1 or 2, wherein the requesting (220; 320) of the additional information comprises requesting map information of a digital road map associated with the position data.

4. Method (200; 300) according to claim 3, wherein the map information comprises attributes and / or topological information associated with the position data.

5. Method (200; 300) according to any one of the preceding claims, wherein the requesting (220; 320) of the additional information comprises requesting topological data associated with the position data.

6. Method (200; 300) according to any one of the preceding claims, wherein the transmitting (230; 330) of the additional information comprises transmitting topological data from map tiles of a digital road map associated with the position data.

7. Method (200; 300) according to claim 5 or 6, wherein the requesting (220; 320) of the additional information further comprises requesting at least one attribute associated with the topological data, and wherein, in response to the requesting (220; 320), the at least one attribute is transmitted from the server (110) to the driver assistance system (120).

8. Method (200; 300) according to claim 4 or 7, wherein the transmitting (230; 330) of the at least one attribute is carried out in a data format adapted to the attribute.

9. Method (200; 300) according to claim 8, wherein the data format comprises a unique identification of the data format and a description of data types contained in the data format.

10. Method (200; 300) according to any one of claims 7 to 9, wherein the at least one attribute comprises a variable attribute.

11. Method (200; 300) according to claim 9 or 10, wherein the description of the data types contained in the data format comprises an identification of a variable attribute and a period of validity assigned thereto.

12. Method (200; 300) according to claim 9 or 10, further comprising: informing (360) the driver assistance system (120) about a changed attribute.

13. Method (200; 300) according to claim 11 or 12, wherein the requesting (220; 320) of at least one attribute comprises a renewed querying (370) of the attribute after expiry of its period of validity.

14. Method (200; 300) according to any one of the preceding claims, wherein a communication between the server (110) and the driver assistance system (120) is carried out via an in-vehicle bus system.

15. Method (200; 300) according to any one of the preceding claims, wherein the transmitting (210; 310) of the position data comprises exclusively transmitting the position data and wherein the transmitting (220; 320) of the additional information comprises exclusively transmitting map information.

16. System (100) for providing data for a driver assistance system (120) of a motor vehicle, comprising: at least one driver assistance system (120) which is configured to receive position data relating to a position of the motor vehicle and, to request the additional information (150) from a server (110) only upon demand for additional information (150) relating to the position data.

17. The system (100) according to claim 16, further comprising: a server (110) which is configured to transmit the additional information (150) to the driver assistance system (120) in response to the request.