本发明一般涉及一种用于为机动车的驾驶员辅助系统提供数据、特别是提供基于地图的或地理参考的数据并且特别是为机动车的电子地平线提供数据的方法和装置。
背景技术
导航系统也可以用作车辆的其它驾驶员辅助系统(英文缩写为adas，即先进驾驶辅助系统)的传感器，以便改进或者扩展其它驾驶员辅助系统的功能范围。在此，驾驶员辅助系统指的是机动车中用于在特定的行驶状态下支持驾驶员的电子的附加装置。在这种情况下，处于重要地位的经常是安全性，但也还有驾驶舒适性的提高。另一个方面则是改善经济性。为了支持驾驶员辅助系统，可以将信息娱乐系统的导航系统或下文中也称为主单元的所谓的主机单元(head-unit)的与地点有关的信息传送给车辆内的驾驶员辅助功能的一个或多个其它的控制器。主机单元此时在一定程度上起到服务器的作用，而各个控制器或驾驶员辅助系统则用作客户端。所传送的与地点有关的信息在专业术语中经常也被称为电子地平线(elektronischerhorizont)。
已知用于在数字道路地图的基础上生成电子地平线的系统。这些系统利用不同的协议、如adasisv2、adasisv3和bmwadas2.1在车辆网络中分配信息。在此背景下典型地使用can总线(can＝控制器局域网络)作为通信信道。所述协议基于形式为一条或多条路径(adasisv2和v3)或树(adas2.1)的经提取的导航图。导航图被用作用于相应的属性化并且进而用于信息分配的参考系统。下文中，特征和/或这些特征的特性可以理解为是数字道路地图的属性。特征是在数字道路地图中被适宜地考虑到的针对实际道路的地点呈现形式(
在此通常是主机单元负责决定，从数字导航地图中接收哪些要素(基于拓扑结构的链接或片段)到电子地平线中。因此主机单元可以用不同的算法来确定最有可能行驶的行驶路径(也被称为mpp＝最有可能的路径)并且在该方向上探索地图。紧接着可以视所使用的策略而定进入相应的交叉路探索。换句话说，电子地平线可以包含前方路网的信息(拓扑结构)，其中，仅从车辆的当前的位置能到达并且有一定概率实际上也会行驶的道路才是相关的。
相应的电子地平线的长度在此受到不同的因素，如相应区域中的信息的密度或格式中所使用的编码的密度的影响。电子地平线的预测长度大致为500m至6km，取决于使用电子地平线的驾驶员辅助系统的要求。
因为车辆中的不同的驾驶员辅助功能需要不同的预测范围，所以电子地平线可以有不同的呈现形式。例如2d呈现形式，其除了最有可能的行驶路径外也包含相应的分叉，或者1d预测，其仅遵循最有可能的行驶路径或通常遵循计划的路线的走向。因此可以将不同程度的信息提供给不同的驾驶员辅助功能。
上述目前可用的用于传输电子地平线的驾驶员辅助协议或adas协议已经达到了目前传输可能性的极限。预测范围的延伸大小或预测长度都受到现有的与地点有关的属性(例如限速、坡度、曲率等)的密度的限制。无法添加新的属性/特征，因为消息或协议通常不再能添加新的字段。用于未来的驾驶员辅助系统的高精度地图数据、例如精确的车道模型包括基础的几何图形在内的传输用当前基于can的adas协议都无法实现。通过变更基础层、例如从can变更到以太网带来的带宽的提高在这些挑战中的用处仅是受限的，因为在adas协议中所使用的编码格式已经不适用于这类信息。这种解决方案遵循例如adasisv3协议。不过，这里也再次将各个路径设置为导航地图的一部分。
当前已知的adas协议和实施方案的另一个缺点是这样一些事实，即，主机单元作为基于导航的信息的源头执行最有可能的行驶路径的计算。由此，所有连接的驾驶员辅助功能必须用这条最有可能的行驶路径工作。不过不同的驾驶员辅助功能可能偏爱不同呈现形式(
通过电子地平线的当前呈现形式的固定式结构化的协议，必须在构想相应协议的时间点上就已经确认和定义了形式为属性的全部所需的信息。事后的扩展以及附加的属性通常与新的开发范围和相应的成本相关联。因此电子水平线的当前的呈现形式极为僵化并且无法灵活地对未来的驾驶员辅助功能的新要求、如高度自动化的驾驶做出响应。
在当前的和主要是未来的车辆之间用相应的后台服务的交联正在稳步增长。由此可以始终较快地更新地图信息。在开始更新相应的地图的拓扑，直至高度动态地更新交通状况和可变交通标记的当前显示的值。这些高度动态的数据同样无法借助电子地平线的当前的呈现形式在车辆中传输。
车辆中的不同的驾驶员辅助功能对由数字地图示出的信息的呈现形式有不同的要求。一些驾驶员辅助功能需要车辆前端中的在当前位置上的以及沿整个路网(拓扑结构)的极为详细的信息。其它的驾驶员辅助功能则仅需要一些针对拓扑结构和/或针对当前的车辆位置的属性(例如当前允许的最高速度)。电子地平线的不同的可用的呈现形式在当前无法灵活地与这些要求相匹配。所有的功能必须联合到统一的接口上以及因此要应付有时过多或过少的信息。
技术实现要素：
因此可以被视作本发明的任务的是，对涉及在机动车中提供基于地图的数据的已知的现有技术进行扩展设计和改进。
该任务通过带有独立权利要求的特征的方法和装置解决。有利的设计方案和扩展设计方案是从属权利要求的技术方案。
按照第一个方面，本发明的实施例创造出一种用于为机动车的驾驶员辅助系统提供数据、特别是提供基于地图的或地理参考的数据的方法。所述方法包括间接或直接地将涉及机动车的当前的或未来的位置的位置数据例如从车辆内部的或车辆外部的定位和/或导航单元传送给驾驶员辅助系统。在驾驶员辅助系统需要关于位置数据的附加信息时，驾驶员辅助系统在车辆内部的或车辆外部的服务器上请求所述附加信息。因此发生了按需控制的请求，没有需要就没有请求，有需要就有请求。作为对请求的响应，车辆内部的或车辆外部的服务器将所述附加信息间接或直接传送给驾驶员辅助系统。
因此建议提供不同层面上的导航数据。位置数据(必要时当前的位置)被定期从定位或导航单元作为一种基础信息传送给驾驶员辅助系统。带有当前的车辆位置的位置数据的传送因此可以被视作是基础的或必需的传送。驾驶员辅助系统或其所配设的控制器仅在需要时请求另外的涉及位置数据或当前的车辆位置的数据，例如当前的车辆位置的属性或针对当前的车辆位置的另外的拓扑数据。附加信息也可以涉及地理参考的易变的数据：例如天气、交通流等。各实施例例如可以有利地用于为电子地平线可缩放地提供基于地图的数据。
导航单元可以涉及固定地安装在车辆中的信息娱乐或导航主机单元。但也可以考虑这样一些实施例，在这些实施例中，可以使用没有被固定地装在车辆中的定位或导航系统作为导航单元，例如智能手机或类似物。导航单元因此可以构造用于提供至少当前的和/或未来的位置数据。也可以涉及没有进一步的功能性的简单的位置传感器。但导航单元也可选具有更为复杂的功能，如路线计算和/或提供其它基于地图的属性。服务器同样可以涉及安装在车辆中的信息娱乐或导航主机单元(主单元)。但也可以考虑车辆外部的服务器(例如因特网)。
位置数据在一些实施例中指的是当前的车辆位置的坐标。但位置数据可以包括未来的位置数据或沿着被视作极有可能遵循的规划好的路线或路径的坐标。车辆的当前的或未来的位置(当前车辆位置currentcarposition，ccp)可以用不同的细节程度加以描述，例如在wgs84-坐标(世界测地系统1984)中的实际位置，即例如基于gps和车辆里程表的未经加工的位置。另一种可能性例如是对当前的车辆位置所处的地图局部的说明(例如地图瓦片，瓦片id)。除此之外还可以说明该地图局部的拓扑元素，例如节点或边缘(链接id)，车辆在当前处在该拓扑元素上。为了更为准确地识别在地图局部中的当前的车辆位置，也还可以额外说明一个所谓的偏移量，该偏移量表明，车辆在拓扑元素上当前位于哪里。其它的格式当然同样可行并且取决于它们在接收的控制器中的可用性。
位置数据是在此提出的受需求控制的数据提供的基础信息，这些基础信息由定位或导航单元至少提供给驾驶员辅助系统。可以将这些信息也理解为是所建议的协议的一个基础层。与此相对，附加信息可以理解为是协议的受需求控制的附加层。
在一些实施方式中，位置数据的传送可以周期性地或循环地进行，例如在驾驶员辅助系统在定位或导航单元上注册之后。取代传统的推送消息，所建议的adas协议在此可能在变型方案之间有所不同：当前的位置数据的循环的传输和关于附加的(基于地图的)信息的受需求控制的请求/应答。循环的传输可以用于，向接收者循环地供应相关的并且被接收者请求的数据。在所建议的adas协议的情况下，仅当前的位置的传输属于此。可选可以循环附加地传送在当前的位置上有效的属性的选择。在当前的位置上的属性可以是通过可配置的数据格式、所谓的数据定义(datadefinition数据格式描述)可写的属性。属于此的例如有：行驶车道的数量、道路等级、道路名称、限速、坡度值等。
除了定期传送位置数据外，附加信息的受需求控制的请求在一些实施方式中可以包括数字道路地图的与位置数据关联的地图信息的请求。换句话说，驾驶员辅助系统客户端此外还具有这样的可能性，即，通过请求/应答接口直接请求地图信息。地图信息在此可以包括与位置数据关联的、即涉及地点的属性和/或涉及地点的拓扑信息，地图信息不是在定期的基础上，而是在请求的基础上，由服务器(亦即例如由主单元)传送给驾驶员辅助系统。在此，特征和/或这些特征的特性被理解为是数字道路地图的属性。特征是在数字道路地图中被适宜地考虑到的针对实际道路的地区呈现形式的可能性，如道路等级、交通指示牌、限速、弯道半径、行车道状况等。这些特征具有与地点相关的特定的特性。而拓扑信息或数据则指的是路网结构并且在此可以例如说明在交叉路口上的转弯限制。拓扑信息可以例如是在路网图中的节点和边缘，即在图中两个决策点(例如交叉点)之间的连接。
地图信息的基础是路网的拓扑。这种拓扑可以以图像的形式存放在数字道路地图中。然后可以将任意的信息以属性的形式储存到该图像的元素(边缘和节点)上。在所建议的adas协议的一些实施方式中，所述拓扑可以与属性分离。也就是说，对超出当前位置的地图请求，驾驶员辅助系统客户端可以用各种方法来询问所述拓扑并且紧接着询问所需的形式为这些拓扑元素的属性的信息。
在一些实施方式中，附加信息的受需求控制的请求因此可以首先包括对与位置数据关联的拓扑数据的请求。在这些情况下，附加信息的传送可以包括来自数字道路地图的与位置数据关联的地图瓦片的拓扑数据的传送。这允许了按需为驾驶员辅助系统提供大致围绕位置数据的拓扑数据。因此根据请求，视需求而定，将一个或多个拓扑元素(节点、边缘等)传送给驾驶员辅助系统。未规定预定义量的有待传送的拓扑数据。客户端要么可以仅询问当前行驶的道路区段(形式为当前的链接和关于所连接的链接的知识)，要么询问来自拓扑结构的更大的局部。所述局部可以以确认好的瓦片示意图为基础、例如以level13的nds瓦片示意图为基础。
当客户端可以获得拓扑信息时，那么该客户端可以针对所述拓扑内的任意元素询问任意属性。在获得拓扑数据后，那么就可以按需由驾驶员辅助系统在车辆内部或车辆外部的服务器上还请求与拓扑数据关联的属性。附加信息的请求在一些实施例中因此也可以包括对至少一个与拓扑数据关联的属性的请求。作为对所述请求的响应，所述至少一个属性可以由服务器传送给驾驶员辅助系统。在此也发生了对属性的受需求控制的请求，因而仅当驾驶员辅助系统需要或想要所述属性时才发生所述属性的传送。因此可以有效且按需地使用传输资源。
在一些实施例中，对拓扑数据和/或属性的受需求控制的请求也等同于驾驶员辅助系统针对未来对所请求的拓扑数据和/或属性的预订。在这种实施方式中，请求已经足以向服务器表明对相应的数据的需求，因而服务器可以将这些数据在未来“未经要求地”例如周期性地或在属性改变时传送给驾驶员辅助系统。
为了询问地图属性，一些实施例建议了一种机制，该机制允许在协议层面上就提前具体地说明了如何传输信息，但允许在之后的时间点对已传输的数据的描述。借助上面已经提到的数据定义可以确定，形式为原始的数据类型(例如整数字段)的任意信息可以处在一个拓扑元素上或所述ccp上。数据类型的意义可以通过数据定义的描述而确定。更新后的数据定义可以时不时提供给主机单元，以便能对新的驾驶员辅助系统做出响应。可以为每个数据定义分配一个单义的id，该id可以是adas协议的组成部分。借助该id可以标识相应的数据定义并且为原始的数据类型指定意义。按照一些实施例，可以以一种与属性相匹配的数据格式传送所述至少一个属性。在此，所述数据格式可以包括数据格式的单义的标识和对在该数据格式中包含的数据类型的描述。
在导航区域中存在多个可能频繁变化的数据，例如可变交通标记或交通流。这些数据属于易变的或动态的数据。在所建议的adas协议中，这些数据同样可以打包在数据定义中并且额外还被分类为动态数据并且获得相应的使用周期。换句话说，所述至少一个属性包括可变的属性。在一些实施例中，对包含在数据格式中的数据类型的描述可以包括可变的属性的标识符和配属于该属性的有效期限。
在协议的不同的实施方案中，可以单独处理可变的属性。在一个例子中，客户端可以在使用寿命或有效期限到期后询问新的数据。换句话说，请求至少一个属性可以包括在该属性的有效期限到期后重新询问该属性。当已经询问的动态的数据发生改变时，附加或备选地，可以单独地通知客户端。客户端然后可以决定，它是否重新调用这些数据。在这些实施方式中，所述方法可以包括通知驾驶员辅助系统属性已改变的步骤。若客户端不重新调用这些数据，那么也就不再需要通知客户端这些数据将来的进一步的变化。
在一些实施例中进行位置数据和有关车辆内部的总线系统的附加信息的传送。可能的总线系统例如是现场总线如can、flexray或lin(局部互联网)。其它的实施例附加或备选也允许了通过以太网或其它局域网(lan)技术的传送。
按照另一个方面，各实施例创造了一种用于为机动车的驾驶员辅助系统提供数据的系统。该系统可以包括定位或导航单元(例如主机单元、驾驶员辅助系统服务器)，该定位或导航单元被构造用于将涉及机动车位置的位置数据传送给驾驶员辅助系统(或配属于该驾驶员辅助系统的控制器)。该系统还包括驾驶员辅助系统(或配属于该驾驶员辅助系统的控制器)，该驾驶员辅助系统被构造用于，接收位置数据，并且在需要关于位置数据的附加信息时在车辆内部或车辆外部的服务器上请求附加信息。服务器被构造用于，作为对请求的响应，将所请求的附加信息传送给驾驶员辅助系统。
按照另一个方面，提供一种驾驶员辅助系统(或配设给该驾驶员辅助系统的控制器)，该驾驶员辅助系统被构造用于，从定位或导航单元接收涉及机动车的位置的位置数据，并且在需要关于位置数据的附加信息时，在导航单元或服务器、特别是车辆内部的主单元上请求附加信息。
按照一个附加的方面，也提供一种服务器，特别是提供一种车辆内部的主单元。该服务器被构造用于，将涉及机动车的位置的位置数据传送给驾驶员辅助系统，并且作为对驾驶员辅助系统的请求的响应，将关于位置数据的附加信息传送给驾驶员辅助系统。
adas协议的所建议的受需求控制的划分允许了强大的缩放效果(skalierungseffekt)：仅需要在当前位置上的信息的简单的驾驶员辅助功能仅需要评估当前的ccp信息，而复杂的驾驶员辅助功能则可以通过询问拓扑和相应的数据定义来询问任意复杂的信息直至高度具体的行车道模型。
划分成拓扑和属性同样实现了强大的缩放效果：客户端可以自行决定，它在哪个范围内请求哪些详细的信息。客户端通常可以比服务器在更弱的控制器上运行并且因此也具有更少的存储器。客户端因此可以视可用的存储器和所需的信息内容而定形成其请求。客户端由此可以自行决定其需要处理多少信息以及何时处理。在传统的adas协议中，这一点从一开始就被限定并且事后不可以调整。因此例如通过传统的adas协议仅在伴随较大的干预的情况下才可以传输高度具体的行车道路模型。
所建议的协议得到使用并且可以灵活地对变化做出响应，因为在定义形式为有待传输的数据格式的协议的时间点上还不必确定传输哪些信息。因此新的信息也可以在协议的使用周期内以新的数据定义的形式添加。现有的客户端可能无法评估这些信息，但也不会询问这些信息。新的客户端知道了新的数据定义并且然后就可以处理这些数据定义。
通过所建议的办法可以使协议非常有效地处理动态数据。传统的协议不允许任何动态的信息，因为一经传输的信息就不再能被改变。也就是说，在传统的协议中必须传输所有新的信息，而在所建议的协议中则也可以在客户端被通知更新后重新传输一些信息。
附图说明
接下来参照附图详细阐述本发明的一些示例性的实施例。图中：
图1示出了用于为机动车的驾驶员辅助系统提供数据的一种示例性的系统的示意图；
图2示出了在主机单元和驾驶员辅助系统之间的数据交换的流程；以及
图3示出了按照一个实施例在客户端和服务器之间的可能的传输的例子。
具体实施方式
现在更为详细地参照示出了一些实施例的附图来说明不同的实施例。
在对仅示出了一些示范性的实施例的附图的下列说明中，相同的附图标记可以标注相同的或类似的部件。此外，可以为多次在一个实施例或一个附图中出现的、但关于一个或多个特征被共同说明的部件和物体使用概括性的附图标记。用相同的或概括性的附图标记说明的部件或物体，关于单个、多个或全部的特征、例如关于它们的尺寸设定，可以被实施成相同的，但必要时也可以实施成不同的，倘若说明书没有明确或含蓄地另行说明的话。
尽管可以以不同的方式修改和更改实施例，但在图中的实施例作为示例示出并且在此文中加以详细说明。不过要明确的是，无意使实施例局限于相应公开的形式，而是应当覆盖各实施例更确切地说所有处在本发明范围内的功能上的和/或结构上的变型方案、等效方案和备选方案。相同的附图标记在整个附图说明中都指的是相同的或类似的元件。
需注意到，一个被指与另一个元件“连接”或“耦联”的元件可以与所述另一个元件直接连接或耦联，或者它们之间可以存在一些元件。当一个元件被指与另一个元件“直接连接”或“直接耦联”时，那么就它们之间就不存在任何元件。被用来描述元件之间的关系的其它的概念，应当以类似的方式加以阐明(例如“之间”相对“直接在这之间”、“邻接”相对“直接邻接”等)。
在本申请中使用的术语，仅用于说明特定的实施例并且不应限制所述实施例。如本申请中所使用的那样，单数形式“一个”和“该”也包含了复数形式，只要上下文中没有明确地另行说明。此外还要阐明的是，在本申请中使用的诸如“包含”、“包含了”、“具有”和/或“有”，说明了所述特征、全部的数字、步骤、工作流程、元件和/或部件的存在，但并没有排除一个或多个特征、全部的数字、步骤、工作流程、元件、部件和/或一个或多个特征、全部的数字、步骤、工作流程、元件、部件构成的组的存在或添加补充。
图1示意性示出了用于为机动车的驾驶员辅助系统提供数据、特别是为电子地平线提供数据的一个示例性的系统100。
系统100包括车辆内部的主机单元110作为服务器和一些与该主机单元耦联的驾驶员辅助系统120-1、120-2、120-3或者配属于这些驾驶员辅助系统的控制器作为客户端。主机单元110可以例如是配属于机动车的信息娱乐系统。主机单元可以集成了娱乐电子器件、因特网技术、舒适性操作以及导航的功能。不同的驾驶员辅助系统120-1、120-2、120-3可以例如通过车辆内部的数据总线、例如can总线耦联到主机单元110上。驾驶员辅助系统120-1、120-2、120-3在一些实施例中可以至少部分实现机动车的自主驾驶或者支持驾驶员。
主机单元110为此有定期地、例如周期性地或循环地将当前的车辆位置数据130传送给所连接的驾驶员辅助系统120-1、120-2、120-3。车辆位置数据在某种程度上可以说是在主机单元110和驾驶员辅助系统120-1、120-2、120-3之间传输的信息的最低限度。要提及的是，车辆位置数据(当前的和未来的车辆位置数据)也可以来自另一个无需必须固定安装在车辆中的适用的导航单元。
视功能性而定，驾驶员辅助系统120-1、120-2、120-3对当前的车辆位置数据的附加信息有着不同的需求，其中，附加信息可以涉及数字的道路地图的与位置数据关联的(亦即地点相关的)地图信息。因此在该示范性的实施例中，驾驶员辅助系统120-1、120-2、120-3被相应地构造用于，在相应需要针对位置数据的附加信息时，在主机单元110中请求相应需要的附加信息。在其它实施方式中，附加或备选地可以在车辆外部的服务器中请求所述附加信息。所述附加信息通常不仅在车辆位置上需要，而且在车辆周围环境中、例如沿着被视为很可能遵循的规划好的路线或路径也需要。除了位置数据外，针对规划好的路线或类似路线的信息也可能对其它的请求起重要作用。相应的请求在图1中用140-1、140-2、140-3标注。作为对相应的请求140-1、140-2、140-3的响应，主机单元110将相应请求的附加信息150-1、150-2、150-3传送给相应的驾驶员辅助系统120-1、120-2、120-3。在驾驶员辅助系统120-1、120-2、120-3和主机单元之间因此分别发生了单独需要的附加信息、如基于地图的数据的一种受需求控制或按照需求的交换。因此可以单独地给每一个驾驶员辅助系统120-1、120-2、120-3提供不同的附加信息。
第一驾驶员辅助系统120-1的除了位置数据外所需的信息150-1例如可以涉及一个或多个在当前的位置上有效的地图属性(例如允许的最高速度)，而第二驾驶员辅助系统120-2的除了位置数据外所需的信息150-2则可以例如包括关于位置数据的拓扑数据、如路网要素。第三驾驶员辅助系统120-3可以例如既对附加的拓扑数据感兴趣也对作为除位置数据外所需的信息150-3的涉及拓扑数据的属性感兴趣，并且因此具有最高的单独的数据需求。驾驶员辅助系统120-3可以例如实施具有较高数据需求的较为复杂的驾驶员辅助功能(例如自适应巡航)。
在主机单元110和驾驶员辅助系统120-1、120-2、120-3中的一个驾驶员辅助系统之间的数据交换的基本流程在图2的示意性的消息顺序图200(英文缩写msc)中示出。
首先在步骤210中涉及位置数据地将机动车的当前的位置由主机单元110传送给驾驶员辅助系统(fas)120。需要时，在步骤220中驾驶员辅助系统(fas)向主机单元请求关于位置数据的附加信息(例如属性和/或拓扑数据)。然后在步骤230中主机单元110将所请求的或所需的附加信息发送给驾驶员辅助系统(fas)。
在借助图2较为泛泛地略述了在主机单元110和驾驶员辅助系统(fas)之间的通信之后，现在借助图3说明一个具体的实施例。在图3中，在所建议的协议的一个实施例中示出了在驾驶员辅助系统(adas客户端)120和主机单元(服务器)110之间的可能的通信。
客户端120在登陆服务器110后借助消息310被周期性地提供当前的车辆位置。在所示的例子中，将形式为瓦片id(tileid)、链接id(edgeid)和链接上的偏移量的当前的车辆信息传递给客户端120。在此，瓦片id指的是当前的车辆位置所处的地图局部。链接id指的是在该地图局部内的拓扑元素，例如节点或边缘，车辆当前处在该拓扑元素上。偏移量表明，车辆当前具体处在拓扑元素上的哪个地方。
在这种基础信息310的基础上，客户端120可以附加地询问所需的拓扑信息，参看步骤320。在此处所示的例子中，基于简单的位置信息310，在主机单元110上请求带有示例性的瓦片id0815的拓扑瓦片，该拓扑瓦片在接下来的步骤330中也被传送给客户端120。
视信息需求而定，客户端120可以紧接着在步骤340中询问拓扑瓦片0815所需的进一步的地图属性，例如涉及拓扑瓦片的一个或多个边缘(例如道路)的允许的最高速度。客户端120为此可以向主机单元110发送dataid(在此:dataid＝4711)，该dataid描述了期望的地图属性或数据定义。借助dataid可以识别相应的数据定义并且为原始的数据类型指派一个意义。
在接下来的步骤350中，主机单元110将对应dataid＝4711的所请求的属性以由与此对应的数据定义确定的数据格式发送给客户端120。按照一些实施例，可以以与该属性匹配的数据格式(数据定义)传送所述至少一个属性。在此，所述数据格式可以包括数据格式或属性的单义的标识和对包含在该数据格式中的数据类型的描述。
按照所示的例子，由主机单元110在步骤350中传送的属性还可以额外具有作为动态数据的分类(“istemporaltile”＝yes)并且必要时具有相应的使用期。换句话说，所述至少一个属性可以包括可变的或易变的属性。在一些实施例中，对包含在数据格式中的数据类型的描述因此可以包括可变的属性的识别符和配属于该可变的属性的有效期限。当在所请求的数据中有动态的数据时，在更新这些数据时客户端120可以被通知该更新。主机单元110又可以例如通过car2x通信技术或后台服务被通知所述更新。在所示的例子中，在步骤360中，客户端120被主机单元110通知附属于拓扑瓦片0815的属性4711发生改变，因而客户端120在需要时在步骤370中可以在主机单元110中请求已改变的属性数据。最后，主机单元110就将所请求的已改变的属性数据发送给客户端120。
概括而言，一些实施例因此在循环的基础传输和附加的请求/应答之间有所区分。循环的基础传输可以用于循环地向接收器供应相关的并且由该接收器请求的基础数据。在所建议的adas协议的情况下，当前的位置的传输和可选地在当前的位置上有效的地图属性的选择均属于此。此外，客户端具有这样的可能性，即，通过受需求控制的附加的请求/应答接口直接请求地图信息。实施例因此可以达到比迄今为止的adas方案更高的灵活度。
在之前的说明、接下来的权利要求和附图中公开的特征既可以单独地也可以以任意组合实施，并且都对实施例在其不同的设计方案中的实现很重要。
尽管一些方面是在装置的背景下加以说明，但应了解的是，这些方面也是对相应的方法的说明，因而装置的一个模块或一个结构元件也可以理解为是相应的方法步骤或方法步骤的特征。与此类似，结合方法步骤说明或作为方法步骤说明的方面，也是对相应的装置的相应的模块或细节或特征的说明。
视特定的实施要求而定，本发明的实施例、至少本发明的实施例的一部分，可以在硬件或软件中实施。实施可以在使用数字的存储介质，例如软盘、dvd、蓝光碟、cd、rom、prom、eprom、eeprom或闪存、硬盘、或其它磁性的或光学的存储器的情况下执行，电子可读的控制信号储存在该数字的存储介质上，所述电子可读的控制信号与可编程的硬件部件可以这样配合作用或者配合作用，从而执行相应的方法。
可编程的硬件部件可以由处理器、计算机处理器(cpu＝中央处理单元)、图形处理器(gpu＝图形处理单元)、计算机、计算机系统、专用集成电路(asic)、集成电路(ic)、单芯片系统(soc＝系统级芯片)、可编程的逻辑元件或带有微型处理器的现场可编程门阵列(fpga)形成。
数字的存储介质因此是机器可读或计算机可读。一些实施例因此包括数据载体，该数据载体具有电子可读的控制信号，所述控制信号能够与可编程的计算机系统或可编程的硬件部件这样配合作用，从而执行在本文中所说明的方法中的其中一种。实施例因此是在其上记录有用于执行在此本文中所说明的方法中的其中一种的程序的数据载体(或数字的存储介质或计算机可读的介质)。
本发明的实施例通常可以实施为程序、固件、计算机程序或带有程序代码的计算机程序产品或实施为数据，其中，程序代码或数据用于，在该程序在处理器上或可编程的硬件部件上运行时执行其中一个方法。程序代码或数据也可以例如储存在机器可读的载体或数据载体上。程序代码或数据可以另外作为源代码、机器代码或字节代码以及作为其它的中间码存在。
按照一个实施例的程序例如可以以如下方式在执行其中一种方法期间实施该方法，即，该程序读取存储位置或者将单个数据或多个数据写入所述存储位置，由此在晶体管结构、放大器结构或其它电气的、光学的、磁性的或按另一种功能原理工作的构件中可能引起开关操作或其它操作。相应地可以通过读取存储位置由一个程序来检测、确定或测量数据、值、传感器值或其它信息。因此程序可以通过读取一个或多个存储位置来检测、确定或测量参量、值、测量参量和其它信息，并且可以通过写入一个或多个存储位置促成、推动或执行一个行为以及驱控其它的仪器、机器和部件。
上文说明的实施例仅是对本发明的原理的解释说明。显然，其它技术人员了解在此文中说明的布置和细节的变型和改型。因此意在表明，本发明仅通过接下来的权利要求的保护范围进行限定，并不通过借助对实施例的说明和阐述在此文中出现的特殊细节进行限定。