协同驾驶的数据存储装置、数据处理方法及路侧设备

1.本文涉及但不限于协同驾驶领域，尤其涉及协同驾驶的数据存储装置、数据处理方法及路侧设备。


背景技术：

2.协同驾驶技术可以很好地规划车辆的运动，有助于缓解冲突地区的交通拥堵，减少事故。为了实现协同驾驶，需要通过车对车(v2x)通信使每辆车都与对方和路侧设备紧密联系。而限制于计算能力，一些协同驾驶技术中数据存储和处理的效率不高。


技术实现要素：

3.以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。
4.本技术实施例提供了一种协同驾驶的数据存储装置、数据处理方法及路侧设备，可以解决协同驾驶技术中数据存储和处理的效率不高的问题。
5.本技术实施例提供了一种协同驾驶的数据存储装置，包括：
6.接收单元，设置为在预设路段内接收来自至少一辆车辆的通信数据，所述通信数据包括所述车辆的位置和速度；
7.数据处理单元，设置为根据所接收的通信数据，以及内存中预设的活跃数据区中缓存的车辆的通信数据，在所述活跃数据区中添加或移除相应数据；
8.持久化存储单元，设置为对符合预设条件的车辆的通信数据进行持久化存储。
9.本技术实施例还提供了一种路侧设备，包括如上所述的数据存储装置。
10.本技术实施例还提供了一种协同驾驶的数据处理方法，包括：
11.在预设路段内接收来自至少一辆车辆的通信数据，所述通信数据包括所述车辆的位置和速度；
12.根据所接收的通信数据，以及内存中预设的活跃数据区中缓存的车辆的通信数据，在所述活跃数据区中添加或移除相应数据；
13.依据所述内存中预设的活跃数据区中缓存的车辆的通信数据，分别为所述至少一辆车辆制定协同驾驶策略，并发送至对应的车辆。
14.本技术实施例还提供了一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行上述方法。
15.本技术实施例还提供了一种自动驾驶车辆，包括如上所述的数据存储装置。
16.本技术实施例还提供了一种协同驾驶系统，包括如上所述的路侧设备，还包括自动驾驶车辆。
17.本技术实施例提供的数据存储装置设计了一种新型的数据存储模型，通过将接收到的通信数据存储在内存中，在需要时就可以快速读取，有助于缩短进行数据处理的时间，能够满足协同驾驶应用对读写性能的高需求，更好地为制定协同驾驶方案策略提供服务。
18.本技术实施例的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本技术实施例而了解。本技术实施例的其他优点可通过在说明书以及附图中所描述的方案来实现和获得。
19.在阅读并理解了附图和详细描述后，可以明白其他方面。
附图说明
20.附图用来提供对本技术实施例技术方案的理解，并且构成说明书的一部分，与本技术的实施例一起用于解释本技术的技术方案，并不构成对本技术实施例技术方案的限制。
21.图1为本技术实施例中协同驾驶的数据存储装置的结构示意图；
22.图2为一种示例性实施例中数据存储装置的工作过程示意图；
23.图3为一种示例性实施例中跳跃表的结构示意图；
24.图4为一些示例性实施例中非活跃链表的结构示意图；
25.图5为一示例性实施例中进行快照保存的流程示意图；
26.图6为不同数据存储模型处理1秒数据流的平均时间成本示意图；
27.图7为跳跃表的存储模型及b+树的存储模型处理每1秒数据流的平均时间成本示意图；
28.图8为包含非活跃链表的跳跃表的存储模型及不包含非活跃链表的跳跃表的存储模型处理每1秒数据流的平均时间成本示意图。
具体实施方式
29.本技术描述了多个实施例，但是该描述是示例性的，而不是限制性的，并且对于本领域的普通技术人员来说显而易见的是，在本技术所描述的实施例包含的范围内可以有更多的实施例和实现方案。尽管在附图中示出了许多可能的特征组合，并在具体实施方式中进行了讨论，但是所公开的特征的许多其它组合方式也是可能的。除非特意加以限制的情况以外，任何实施例的任何特征或元件可以与任何其它实施例中的任何其他特征或元件结合使用，或可以替代任何其它实施例中的任何其他特征或元件。
30.本技术包括并设想了与本领域普通技术人员已知的特征和元件的组合。本技术已经公开的实施例、特征和元件也可以与任何常规特征或元件组合，以形成由权利要求限定的独特的发明方案。任何实施例的任何特征或元件也可以与来自其它发明方案的特征或元件组合，以形成另一个由权利要求限定的独特的发明方案。因此，应当理解，在本技术中示出和/或讨论的任何特征可以单独地或以任何适当的组合来实现。因此，除了根据所附权利要求及其等同替换所做的限制以外，实施例不受其它限制。此外，可以在所附权利要求的保护范围内进行各种修改和改变。
31.此外，在描述具有代表性的实施例时，说明书可能已经将方法和/或过程呈现为特定的步骤序列。然而，在该方法或过程不依赖于本文所述步骤的特定顺序的程度上，该方法或过程不应限于所述的特定顺序的步骤。如本领域普通技术人员将理解的，其它的步骤顺序也是可能的。因此，说明书中阐述的步骤的特定顺序不应被解释为对权利要求的限制。此外，针对该方法和/或过程的权利要求不应限于按照所写顺序执行它们的步骤，本领域技术
人员可以容易地理解，这些顺序可以变化，并且仍然保持在本技术实施例的精神和范围内。
32.在协同驾驶的过程中，需要通过车对车通信使每辆车都与对方和路侧设备紧密联系。在一些技术中，协同驾驶方案是由一些领先的车辆根据通过车对车通信收集的数据确定的，在后的车辆将自身当前的运动信息发送给领先的车辆，由领先的车辆制定详细的驾驶计划来指导在后车辆未来的运动。在另一些技术中，当在一个相对较大的时空范围内规划车辆的驾驶运动，通常会采用借助于路侧设备的方法，由路侧设备(例如可以是一些基础设施)接收来自其控制区域的车辆的大量数据，并根据这些数据来规划车辆的运动。基于收集到的数据可以制定更复杂的协同驾驶方案，并将协同驾驶策略传递给每个车辆。
33.在实际的场景中，路侧设备采用的数据存储模型往往是传统的关系型数据库。路侧设备控制的道路区域内的车辆会持续地以高频率向路侧设备发送数据，这需要路侧设备在不具备分布式数据存储系统的情况下接受所有的数据，然而，路侧设备的计算能力是有限的，在数据量较大时无法保证数据的写入性能。在制定协同驾驶策略时，需要实时快速查询当前在目标道路区域内的车辆的有用信息，当相关车辆离开该区域时，之前所收集的数据将很快变得无用，实际的情况是，车辆会不断地进入和离开路侧设备的控制区域，这使得在数据被存储在传统的关系型数据库的情况下，数据的查询会很费时，无法保证数据的读取效率。路侧设备对车辆进行计划和调度本身需要占用一定时间，当路侧设备采用的数据存储模型在协同驾驶中无法作出快速响应时，就会增加进行数据处理的时间，这会极大影响协同驾驶的效果。并且，在出现可能的通信故障时，路侧设备采用的数据存储模型并不能够保证鲁棒性。
34.如图1所示，本技术实施例提供了一种协同驾驶的数据存储装置，包括：
35.接收单元，设置为在预设路段内接收来自至少一辆车辆的通信数据，通信数据包括车辆的位置和速度；
36.数据处理单元，设置为根据所接收的通信数据，以及内存中预设的活跃数据区中缓存的车辆的通信数据，在活跃数据区中添加或移除相应数据；
37.持久化存储单元，设置为对符合预设条件的车辆的通信数据进行持久化存储。
38.相比于传统的关系型数据库的数据存储模型，本技术实施例提供的数据存储装置设计了一种新型的数据存储模型。在内存中预设活跃数据区接收来自预设路段内车辆的通信数据，通过将接收到的通信数据存储在内存中，在需要时就可以快速读取，有助于缩短进行数据处理的时间，能够满足协同驾驶应用对读写性能的高需求，更好地为制定协同驾驶方案策略提供服务。通过将车辆的通信数据进行持久化存储，能够为其它可能的研究提供数据，例如：交通流研究、交通信号控制研究和智能车辆测试等研究。
39.一种示例性的实施例中，本技术实施例的数据存储装置还可以包括发送单元，设置为向车辆发送协同驾驶策略。
40.本技术实施例的数据存储装置中，接收单元和发送单元例如可以通过网络通信模块实现，可以采用输入输出复用的reactor模式实现通信数据的输入和输出，也可以采用其它技术来实现通信数据的输入和输出，本技术对此不作限制。数据处理单元的功能例如可以通过处理器对内存的操作实现。持久化存储单元例如可以采用数据库模块实现，可以将符合预设条件的车辆的通信数据存储在硬盘或者云数据库中。
41.一种示例性的实施例中，通信数据可以包括车辆的意图。车辆的意图可以是车辆
在接下来的时间想要执行的行为，例如：变更车道、超车、靠边停车等，根据车辆的意图，结合车辆当前的位置和速度，可以更好地、更加人性化地规划协同驾驶策略。在其他实施方式中，通信数据还可以包括其它信息，例如车辆的识别码、车内乘客的类别信息(例如：孕妇、儿童、老人等)，本技术对此不作限制。
42.图2为一种示例性实施例中数据存储装置的工作过程示意图。如图2所示，数据存储装置的工作过程可以大致划分为步骤a1至a3。步骤a1为数据接收的步骤，在步骤a1中，数据存储装置在预设路段内接收到来自至少一辆车辆的通信数据，从一个事件驱动的等待列表中挑选出预先准备好的数据缓存区(即活跃数据区)，为每一辆车辆更新常驻存储器的数据缓存区，例如，将来自车辆a的通信数据存储在车辆a的通信数据缓存区、将来自车辆b的通信数据存储在车辆b的通信数据缓存区。步骤a2为数据处理的步骤，在步骤a2中，数据存储装置可以根据所接收的通信数据，以及数据缓存区中已经缓存的车辆的通信数据，在数据缓存区中添加或移除相应数据，可以将活跃数据区的数据存储到非活跃数据区。位于数据缓存区的数据都是当前时刻仍在预设路段内行驶的车辆的通信数据，这部分数据是制定协同驾驶策略所需要的实时数据，即在制定协同驾驶策略时，采用本技术实施例的数据存储装置可以直接跟踪到有用的实时数据，由于这部分数据是存储在内存中，读取和写入方便，且能够快速响应，极大地便利了协同驾驶策略的制定。步骤a3为数据持久化的步骤，在步骤a3中，可以预先设置数据持久化策略，当车辆的通信数据满足预设条件时，直接将活跃数据区的数据或非活跃数据区的数据存储到持久化数据集。
43.一种示例性的实施例中，所述数据处理单元根据所接收的通信数据，以及内存中预设的活跃数据区中缓存的车辆的通信数据，在所述活跃数据区中添加或移除相应数据包括：
44.在所述车辆的当前位置位于所述预设路段内、且所述车辆在所述活跃数据区存在缓存数据的情况下，将所接收的所述通信数据添加到所述活跃数据区中该车辆的缓存数据中。这种情况表示该车辆在之前发送过通信数据，且当前仍在该预设路段内行驶，因此只需要将该车辆新发送的通信数据加入到活跃数据区中之前以经存在的对应该车辆的缓存数据中即可。
45.在所述车辆的当前位置位于所述预设路段内、且所述车辆在所述活跃数据区不存在缓存数据的情况下，在所述活跃数据区中创建对应该车辆的缓存数据并存储所述通信数据。这种情况表示该车辆是新加入到该预设路段中的，需要在活跃数据区中创建对应该车辆的缓存数据，并将该车辆发送的通信数据进行缓存，该车辆之后发送的通信数据也将存储在本次创建的对应该车辆的缓存数据中。
46.在所述车辆的当前位置没有位于所述预设路段内、且所述车辆在所述活跃数据区存在缓存数据的情况下，将所述车辆的缓存数据自所述活跃数据区中移除。这种情况表示该车辆已经驶离该预设路段，不需要再对该车辆规划协同驾驶策略，可以将该车辆的缓存数据自活跃数据区中移除，以保证活跃数据区中保存的均是对制定协同驾驶策略有用的通信数据，对制定协同驾驶策略无用的(例如过期的)通信数据可以进行单独处理。
47.在所述车辆的当前位置没有位于所述预设路段内、且所述车辆在所述活跃数据区不存在缓存数据的情况下，将所接收的所述通信数据直接丢弃。这种情况可能是错误接收，对这种情况下接收到的通信数据可以不予处理。
48.一种示例性的实施例中，所述将所述车辆的缓存数据自所述活跃数据区中移除，包括：将所述车辆的缓存数据自所述活跃数据区移动到内存中预设的非活跃数据区中。
49.在示例性实施方式中，可以将新收到的通信数据添加到活跃数据区的缓存数据后，一起移动到非活跃数据区。如图2所示，通过在内存中预先设置非活跃数据区，可以将对制定协同驾驶策略有用的通信数据(可以称为活跃数据)存储在活跃数据区，将对制定协同驾驶策略无用的通信数据(可以称为非活跃数据)保存在非活跃数据区，保证了对制定协同驾驶策略有用的通信数据的实时跟踪，由于活跃数据区、非活跃数据区均位于内存，使得数据转移更加快速，更加有助于数据处理的快速响应。
50.一种示例性的实施例中，所述活跃数据区的缓存数据包括：跳跃表；所述跳跃表的叶子节点以车辆的识别号为键，以与所述车辆的识别号对应的车辆的通信数据为值；来自同一车辆的不同时间节点的通信数据按照时间序列以邻接链表的形式缓存至以该车辆的识别号为键的所述叶子节点，邻接链表的每个节点的数据分别包含：本时间节点对应的本节点的通信数据以及指向下一个时间节点对应的节点的指针；所述叶子节点包含头指针和尾指针，所述头指针指向邻接链表的头节点，所述尾指针指向所述邻接链表的尾节点。
51.本实施例中，采用跳跃表加上多个邻接链表的复合数据结构将在预设路段行驶的车辆的通信数据存储在内存中。在协同驾驶的场景中，位于控制区域(即预设路段)内的每辆车将在每个采样时间点发送其位置、速度、意图和其他信息。这使得协同驾驶数据有以下四个特征：每个数据包的结构都是同质的(数据同质性)；但不同的车辆只允许更新自己的状态(车辆独立性)；如果一个车辆的每个数据包都能被正确接收，会得到一个按时间顺序增长的列表，其元素分别是所接收的数据包(时间有序性)；车辆只有在位于控制区域的时间内发送的通信数据才是有效的，车辆在控制区域以外的通信数据对于协同驾驶是无效的(时间敏感性)。本实施例中设计的上述复合数据结构能够很好的满足上述四个特征的要求，能够合理、有条理、有效率地存储来自车辆的通信数据。跳跃表是一种基于概率的链表数据结构，与平衡二叉树相比，跳过列表算法的渐进预期时间界限与平衡二叉树相同，但结构更简单、运算更快且使用的空间更少。上述复合数据结构能够立即确定一个车辆是否已经被记录，且能够更有效率地对预设路段行驶的车辆进行迭代处理，在迭代处理的速度上优于哈希表的结构或哈希码的算法。
52.图3为一种示例性实施例中跳跃表的结构示意图。如图3所示，b0表示跳跃表的底层节点，称为叶子节点；b1表示跳跃表的一级索引，一级索引可以是从叶子节点中选择出的部分节点；b2表示跳跃表的二级索引，二级索引可以是从一级索引中选择出的部分节点。b1和b2是跳跃表的上层节点，可以在叶子节点中存储数据，上层节点只用于索引，上层节点的层数和数量可以根据叶子节点的数量进行设置，图3中以设置两层上层节点b1和b2为例进行说明，本技术对设置上层节点的层数和数量不作限制。以图3中车辆a为例，跳跃表中车辆a的叶子节点以车辆a的识别号(即车辆a的id)为键，与车辆a的识别号对应的车辆的通信数据(即车辆a的数据)为值，将来自车辆a的不同时间节点的通信数据按照时间序列(时刻t1至时刻tk)以邻接链表的形式缓存至以车辆a的识别号为键的叶子节点，邻接链表的每个节点的数据分别包含：本时间节点对应的本节点的通信数据以及指向下一个时间节点对应的节点的指针。车辆a的邻接链表中记录了时刻t1至时刻tk来自车辆a的通信数据(可以分别称为t1节点至tk节点)，t1节点(即时刻t1的数据)存储了车辆a在t1时刻发送的通信数据，为车
辆a的链表的头节点，t1节点还包含指向下一个节点即t2节点的指针；t2节点存储了车辆a在t2时刻发送的通信数据，t2节点还包含指向下一个节点即t3节点的指针；
…
，依次类推，t
k-1
节点存储了车辆a在t
k-1
时刻发送的通信数据，t
k-1
节点还包括指向tk节点(即时刻tk的数据)的指针，tk节点存储了车辆a在tk时刻发送的通信数据，为车辆a的链表的尾节点。车辆a的叶子节点包含头指针和尾指针，头指针指向车辆a的邻接链表的头节点，尾指针指向车辆a的邻接链表的尾节点。通过叶子节点的尾指针可以方便地确定车辆的实时状态，在制定协同驾驶策略时，可以直接访问最后的数据来获取车辆的实时状态，不需要遍历整个链表，极大地提高了效率，节省了时间。车辆b的叶子节点及其他车辆的叶子节点的结构与车辆a的叶子节点的结构类似，在此不再赘述。
53.在示例性实施方式中，车辆的识别号例如可以是车辆的车牌号、车架号等信息，能够起到对不同的车辆进行区分的作用。可以将车辆的识别号中包含的字母转化为数字，从而将字符串格式转变为数字格式，更加便于进行数据处理。可以将车辆的识别号中包含的任意一个字母转化为两位数字，例如车辆的识别号为a88888，转化为数字格式后可以为0088888。车辆的识别号可以包含在对应车辆发送的通信数据中，或者可以采用其它方式获取，本技术对车辆的识别号的内容、格式、格式转化方式及获取方式等不作限制。
54.在示例性实施方式中，可以采用固定大小的数组对邻接链表进行存储。在内存足够大的情况下可以采用这种实施方式，有助于节省数据处理的时间。在实际应用中，每辆车在预设路段内的行驶时间是不固定的，所发送的通信数据量也无法预知，例如在路况拥挤、车辆发生故障、出现交通事故等情况下将会收到来自同一车辆的更多的数据包。因此，在使用一个固定大小的数组来存储所有可能的数据包的情况下，需要将这个数组设置的非常大以足够应对各种情况，这将会造成内存浪费。在其他实施方式中，可以将邻接链表的元素存储在不连续的内存位置，这种实施方式在管理链表时需要消耗额外的动态内存分配成本，然而会避免存储数据包时的内存浪费。可以根据实际需求选择合适的方式对邻接链表进行存储。
55.一种示例性的实施例中，所述根据所接收的通信数据，以及内存中预设的活跃数据区中缓存的车辆的通信数据，在所述活跃数据区中添加或移除相应数据，包括：
56.在所述车辆的当前位置位于所述预设路段内、且所述车辆在所述跳跃表中存在叶子节点的情况下，在所述跳跃表的相应叶子节点对应的邻接链表中添加所接收的通信数据。这种情况表示该车辆在之前发送过通信数据，且当前仍在该预设路段内行驶，因此只需要将该车辆新发送的通信数据加入到该车辆的叶子节点的邻接链表中即可。
57.在所述车辆的当前位置位于所述预设路段内、且所述车辆在所述跳跃表中不存在叶子节点的情况下，在所述跳跃表中添加新的叶子节点并创建新的邻接链表存储所接收的通信数据。这种情况表示该车辆是新加入到该预设路段中的，需要在跳跃表中添加对应该车辆的叶子节点并创建新的邻接链表存储该车辆发送的通信数据，该车辆之后发送的通信数据也将存储在本次创建的该车辆的叶子节点的邻接链表中。
58.在所述车辆的当前位置没有位于所述预设路段内、且所述车辆在所述跳跃表中存在叶子节点的情况下，将所述车辆的叶子节点自所述跳跃表中移除。这种情况表示该车辆已经驶离该预设路段，不需要再对该车辆规划协同驾驶策略，可以将该车辆的叶子节点自跳跃表中移除，以保证跳跃表中保存的均是对制定协同驾驶策略有用的通信数据，对制定
协同驾驶策略无用的通信数据可以进行单独处理。
59.在所述车辆的当前位置没有位于所述预设路段内、且所述车辆在所述跳跃表中不存在叶子节点的情况下，将所接收的所述通信数据直接丢弃。这种情况可能是错误接收，对这种情况下接收到的通信数据可以不予处理。
60.一种示例性的实施例中，所述在所述跳跃表的相应叶子节点对应的邻接链表中添加所接收的通信数据，包括：
61.在所述邻接链表中保存所述所接收的通信数据，对所述所接收的通信数据的时间戳与所述车辆的邻接链表中当前的尾结点的时间戳进行比较，将所述时间戳较新的通信数据设置为新的尾结点。
62.一种示例性的实施例中，所述对所述所接收的通信数据的时间戳与所述车辆的邻接链表中当前的尾结点的时间戳进行比较，将所述时间戳较新的通信数据设置为新的尾结点，包括：
63.在所述所接收的通信数据的时间戳较新的情况下，在所述车辆的邻接链表中创建所述新的尾结点，将所述所接收的通信数据存储在所述新的尾结点；
64.在所述车辆的邻接链表中当前的尾结点的时间戳较新的情况下，在所述车辆的邻接链表中创建所述新的尾结点，将所述当前的尾结点的通信数据复制到所述新的尾结点，将所述所接收的通信数据存储到所述当前的尾结点。
65.由于无线通信的问题，数据存储装置收到通信数据的顺序可能与通信数据发生的时间顺序并不相同，一些后来收到的通信数据可能是车辆在更早时间发送的通信数据，而在制定协同驾驶策略时，只有最后的通信数据对确定车辆的实时状态是有用的，车辆在更早时间发送的通信数据对于制定协同驾驶策略属于过期的数据。因此，在将新收到的通信数据添加到相应的邻接链表中时，需要将新收到的通信数据的时间戳与当前存储在该车辆的邻接链表的尾节点的通信数据的时间戳进行比较，如果是新收到的通信数据的时间戳较新，可以创建一个新的尾节点来存储新收到的通信数据；如果是当前的尾结点的时间戳较新，可以创建一个新的尾节点来复制前一个尾节点的通信数据，并将新收到的通信数据存储到前一个尾节点。每当有新的节点被添加到邻接链表中时，跳跃表的相关元素也将被更新，以正确跟踪邻接链表的尾节点。当放入新的通信数据时，可不借助跳跃表中邻接链表的头节点，只使用邻接链表的尾结点更新它，从而不需要遍历整个邻接链表。
66.一种示例性的实施例中，所述非活跃数据区的缓存数据包括：非活跃链表；所述非活跃链表的节点以车辆的识别号为键，以与所述车辆的识别号对应的车辆的通信数据为值；同一车辆的不同时间节点的通信数据按照时间序列以邻接链表的形式缓存至以该车辆的识别号为键的非活跃链表中，邻接链表的每个节点的数据分别包含：本时间节点对应的本节点的通信数据以及指向下一个时间节点对应的节点的指针；所述非活跃链表的每个节点包含：所述车辆的识别号、指向所述邻接链表头节点的第一指针以及所述邻接链表。
67.图4为一些示例性实施例中非活跃链表的结构示意图。在车辆离开了控制路段后，可以将跳跃表中该车辆的叶子节点删除，并移动到非活跃数据区的非活跃链表。如图4所示，非活跃链表可以是一个二维的邻接链表，可以将非活跃链表看成是一个特殊的一维链表(主链表)，非活跃链表的每个节点包含：车辆的识别号、车辆的数据链表(子链表)的头节点指针以及链表中通常的后继指针。以车辆a为例，在非活跃链表中车辆a的节点包括：车辆
a的识别号(id号)、指向车辆a的邻接链表头节点的第一指针以及车辆a的邻接链表的后继指针。结合图3和图4，由于跳跃表的叶子节点的邻接链表和非活跃链表共享相同的链表数据结构，因此在移动数据时，可以只记录链表的指针，而不需要任何内存复制操作，移动数据的操作简单。以将车辆b的数据移动到非活跃链表的操作为例，如图4所示，可以在非活跃链表中先创建一个新的主链表的头节点(车辆b链表的头节点)，并使其在链表中的下一个指针指向主链表的前一个头节点(车辆a链表的头节点)，然后，记录下所包含车辆b的索引和相关邻接链表的头指针，作为主链表的车辆b节点的成员。
68.在上述实施例的跳跃表中，跳跃表的空间复杂度为o(n)。在跳跃表中查询数据的时间复杂度为o(logn)。在跳跃表中插入数据(例如插入新的叶子节点，在已有叶子节点的数据链表中插入通信数据等)的时间复杂度为o(1)。在制定协同驾驶策略的过程中，每次进行车辆的运动规划时，跳跃表的每个叶子节点都将以邻接链表迭代的方式被访问，因此，在跳跃表中获取数据的时间复杂度为o(n)。在跳跃表中移动数据的时间复杂度为o(k)。可见，本技术实施例中设计的数据存储结构，算法的时间复杂度较低，有助于保证数据处理的效率。
69.一种示例性的实施例中，所述对符合预设条件的车辆的通信数据进行持久化存储，包括：在所述非活跃数据区内的数据量达到预设的数据量阈值时，对所述非活跃数据区内的车辆的通信数据进行持久化存储。
70.将仍在预设路段内行驶的车辆的通信数据保留在内存中，可以快速提取想要的数据，而不需要耗费时间的磁盘操作。可以将对于制定协同驾驶策略无用的数据(例如驶离预设路段的车辆的通信数据)从内存中删除以节省空间。而已经收集的车辆的历史运动和轨迹数据对于许多其他研究(例如，交通流研究、交通信号控制研究和智能车辆测试)也非常重要，这些数据不应该被简单地丢弃。为了保留这些数据，可以维护一个定期的数据持久化存储。当非活跃数据区内的数据量达到一个预先设定的数据量阈值时，把非活跃数据区内的数据存储到硬盘中，通过将数据从非活跃数据区进行持久化存储，可以避免给活跃数据区内的数据处理带来干扰。可以根据实际的使用场景和需求设置数据量阈值。可以利用磁盘、硬盘或云数据库等手段对数据进行持久化存储，本技术对此不作限制。
71.一种示例性的实施例中，所述对符合预设条件的车辆的通信数据进行持久化存储，包括：按照预设的时间间隔保存所述跳跃表的叶子节点数据的快照。
72.在数据处理过程中可能存在机器关闭、内存损坏或其他意外故障。为了防止数据意外丢失，保证数据安全，数据库系统需要在系统故障后的特定时间内恢复内存中活跃数据区的数据。可以在指定的时间间隔内将内存中的活跃数据的快照写入磁盘。当系统发生故障时，内存可以从磁盘上读取临时文件进行数据恢复。由于车辆的通信数据存储在跳跃表的叶子节点，所以快照的过程只需要遍历和复制叶子节点，而不需要保存整个跳跃表结构。由于跳跃表上层每个扩展节点的随机性，当内存数据恢复时，可以很容易地根据快照数据构建一个新的跳跃表结构。
73.图5为一示例性实施例中进行快照保存的流程示意图。如图5所示，虚线以上的部分表示内存操作，虚线以下的部分表示磁盘操作。系统服务器可以分出一个子进程，先把跳跃表的叶子节点所包含的数据写到磁盘上的一个临时文件中，然后可以用二进制的压缩存储，并取代之前版本的临时文件，使得在磁盘上始终存在最新版本的跳跃表的数据，该子进
程可以周期执行这一快照形成过程。当系统发生故障时，内存可以从磁盘上读取到距离故障发生时间最近的临时文件进行数据恢复。通过定期创建数据的快照而不是日志，可以避免持久化过程中需要提前写日志，简化了临时文件的格式并节省存储空间。
74.一种示例性的实施例中，所述对符合预设条件的车辆的通信数据进行持久化存储，包括：按照预设的时间间隔保存所述跳跃表的叶子节点内尾结点数据的快照。
75.由于制定协同驾驶策略主要操作和关注预设路段内车辆的实时数据，所以持久化操作可以只对跳跃表的叶子节点内邻接链表的尾结点进行快照，从而在进行数据恢复时，能够方便地得到每个车辆的最后状态信息，也可以进一步降低存储和数据操作的成本。
76.本技术实施例提供的数据存储装置，采用了新型的数据存储模型，将来自预设路段内车辆的通信数据放在内存中进行处理，提升了数据处理速度。通过设置活跃数据区和非活跃数据区分别对活跃数据和非活跃数据进行处理，能够保证方便地对制定协同驾驶策略有用的实时数据的关注。采用跳跃表及邻接链表的数据存储结构，符合协同驾驶数据自身所具备的特点，便于更好地、更有效率地进行数据存储和处理；非活跃链表采用二维邻接链表的形式，能够保证数据转移的效率。通过对数据进行持久化存储，一方面有助于保证有充足的内存进行数据存储和处理，另一方面能够支持故障后的数据恢复，有助于稳定运行。
77.本技术实施例还提供了一种路侧设备，包括上述任一实施例所述的数据存储装置。
78.本技术实施例还提供了一种自动驾驶车辆，包括上述任一实施例所述的数据存储装置。
79.一种示例性的实施例中，上述实施例中提供的数据存储装置可以安装在自动驾驶的车辆上，可以由自动驾驶汽车制定协同驾驶策略。例如，在由领先的车辆制定详细的驾驶计划来指导在后车辆未来的运动的场景下，领先的车辆可以采用上述实施例中提供的数据存储装置收集在后车辆的通信数据。在自动驾驶车辆安装有上述数据存储装置的情况下，本技术对制定协同驾驶策略的场景和形式不做限制。
80.本技术实施例提供了一种协同驾驶的数据处理方法，包括：
81.在预设路段内接收来自至少一辆车辆的通信数据，所述通信数据包括所述车辆的位置和速度；
82.根据所接收的通信数据，以及内存中预设的活跃数据区中缓存的车辆的通信数据，在所述活跃数据区中添加或移除相应数据；
83.依据所述内存中预设的活跃数据区中缓存的车辆的通信数据，分别为所述至少一辆车辆制定协同驾驶策略，并发送至对应的车辆。
84.本技术实施例还提供了一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行上述任一实施例所述的方法。
85.为了验证上述数据存储模型的有效性，我们进行了实验模拟，将上述数据存储模型与一些可能的替代方案进行比较。进行对比的实验对象有：上述实施例中采用的跳跃表的存储模型、b+树的存储模型以及mysql数据库的存储模型，其中，跳跃表的存储模型、b+树的存储模型为基于内存的存储模型，mysql数据库的存储模型为基于磁盘的关系型数据库存储模型。实验中使用的机器为：装有英特尔i9 10900x cpu的10核机器，操作系统是ubuntu18.04lts，linux内核版本为5.4.0，内存为金士顿64g，编程语言是c++。
86.我们在一个十字路口场景中测试了上述数据存储模型的性能。根据2021年10月26日12:00至14:00期间在中国延安路和胜利路交叉口收集的经验数据，其中包括中午的高峰时段，再现了不同方向的交通流入率。将车牌中的省份和字母信息编码为类似0088888的格式，根据编码字符串的比较，对b+树和跳跃表的键值进行排序。
87.在实验中，假设路侧设备可以覆盖控制周围半径300米的圆周区域，所控制的区域在每个采样时间戳大致包含300辆车，假设研究区域内的车辆每0.1s向路侧设备单元发送数据包，每个数据包的大小为594字节，因此路侧设备每1s收到的数据总量大约为1776000字节，即1.69m。事实上，每个时间戳控制区域内的车辆数量并不固定，例如，在中午高峰期的12:00-12:30之间车辆较多(可能有400辆)，而在1:00-1:30之间车辆较少(可能有200辆)。两个小时内路侧设备处理的数据总量达到12g。
88.在两个小时的交通仿真的数据操作过程中，对上述不同的数据存储模型分别记录每个数据存储模型每秒数据流处理所需要的时间成本，包括键值查询、数据插入和数据删除等完整操作。为了更好地表示每秒数据流处理消耗的时间成本，并增加曲线的平滑度，我们将记录的数据每10s进行一次平均处理并绘图。
89.为了公平比较，在内存中设计的两个数据存储结构跳跃表和b+树，在深度上需要大致保持相等，即在本实验的数据规模下，占据的内存空间大致相同。考虑到每个时间戳的叶子节点的数量，5度或7度b+树的深度大约是3或4，我们选择相同深度的跳跃表进行比较。对于跳跃表和b+树的实现，我们添加相同的邻接链表和非活跃链表的结构。
90.图6为不同数据存储模型处理1秒数据流的平均时间成本示意图。图6中横坐标表示交通仿真时间(单位为秒，s)，纵坐标表示处理每1秒数据流的平均时间成本(单位为毫秒，ms)。从图6中可以看出，在本次实验环境的数据规模下，在实时读写和存储的性能上，mysql数据库要比基于内存的数据存储模型弱得多，伴随着数据流的收集，mysql需要100ms至230ms来完成对每1秒接收数据的处理，这是一个巨大的延迟，相比之下，b+树和跳跃表对每1秒接收数据的平均处理时间都在20ms以下。
91.图7为跳跃表的存储模型及b+树的存储模型处理1秒数据流的平均时间成本示意图。从图7中可以看出，在流量高峰期，b+树处理每1秒数据流的平均时间成本大致为18ms至20ms，跳跃表处理每1秒数据流的平均时间成本大致为14ms至16ms；而在流量低谷期，b+树处理每1秒数据流的平均时间成本大致为10ms至12ms，跳跃表处理每1秒数据流的平均时间成本大致为8ms至10ms。由于在邻接链表结构的设计中，每辆车的邻接链表只占据了跳跃表或b+树底部的一个叶子节点，这使跳跃表或b+树的主结构不会过度膨胀。此外，当车辆离开控制区时，叶子节点也将从跳跃表或b+树的主结构中删除，这使得整体的数据处理时间更加稳定。可见，使用基于内存的数据存储模型，可以实现每秒钟数据流的10ms级别的处理速度，这样的时间复杂度对于路侧设备收集和存储实时数据是可以接受的。
92.从图7中可以发现，跳跃表的整体性能比b+树的要好。原因是b+树的每一次插入和删除操作都需要检查节点的度，这可能会触发节点的分裂和合并，并在层次结构中向上传递以保持树的平衡。而跳跃表则直接连接邻接链表中的节点所在层的前后邻居节点，因此它的效率更高。虽然b+树的自平衡操作使得键的查询有一个更加稳定的时间，但平衡时间的代价远远大于这里节省的时间。
93.图8为包含非活跃链表的跳跃表的存储模型及不包含非活跃链表的跳跃表的存储
模型处理1秒数据流的平均时间成本示意图。在不设置非活跃链表的跳跃表中，过期的数据不会及时从跳跃表中删除，图8示出了这种做法对数据处理性能带来的影响。从图8中可以看出，在其他条件相同的情况下，设置非活跃链表的跳跃表的平均处理时间比不设置非活跃链表的跳跃表的平均处理时间更短，可见设置非活跃链表对数据存储模型的性能提升是非常明显的。在不设置非活跃链表的情况下，不能够实时地将过期的数据从跳跃表中删除，当来自车辆的新的通信数据等待插入时，搜索时间将更长，导致了平均处理时间的显著增加。而且，随着交通仿真时间的增加，二者时间成本的差距也越来越大。尽管将跳跃表的深度从3增加到4会提高键值搜索的效率，在没有非活跃链表的情况下能够减缓时间成本的增长，但当累积了两小时的车辆数据后，不带有非活跃链表的跳跃表的平均处理时间仍会增加近50％。此外，在不设置非活跃链表的情况下，就不能够对活跃数据和非活跃数据进行分离处理，也就无法直接遍历活跃车辆的数据。因此，非活跃链表的设计是有效且必要的。
94.根据以上实验结果可以看出，在处理数据的整体性能上，基于跳跃表的数据存储结构要优于基于b+树的数据存储结构。基于跳跃表的数据存储模型在有足够内存空间的条件下可以完成高频率的数据传输任务。非活跃链表对数据处理也起到了重要作用。实验结果还显示，4层跳跃表的性能略好于3层跳跃表，7度b+树的性能也略好于5度b+树。但是，在路侧设备操作的数据规模下，4层跳跃表、7度b+树分别相比于3层跳跃表、5度b+树的改进幅度很小，而且内存成本增加很多，因此，在选择合适的基础数据结构时要注意时间成本和内存成本的平衡。本技术实施例提供的数据存储模型可以应用在真实的协同驾驶场景中，可使路侧设备在短时间内完成控制区域内车辆的数据汇聚及处理，产生比广泛使用的关系型数据库更好的性能。
95.本技术实施例还提供了一种协同驾驶系统，包括上述实施例的路侧设备，以及自动驾驶车辆。
96.在一些示例性实施例中，网联自动驾驶车辆安装有v2i通信设备和gps定位系统，能够保证车辆与路侧设备的实时通信，从而将车辆的精确定位信息和运行轨迹数据等信息发送给路侧设备。路侧设备搭载的服务器具有高性能cpu、较多的内存空间(64g以上)和磁盘空间(1t以上)，并可以与云端数据库建立连接。路侧设备搭载的数据存储模型的数据结构可以采用c++编程语言实现。
97.在协同驾驶系统中，事先设定网联自动驾驶车发送数据的周期c(单位：秒)，非活跃数据累积上限阈值v(单位:gb)，数据持久化备份周期m(单位：秒)。网联自动驾驶车每经过周期c向路侧设备发送一次数据包，路侧设备通过网络i/o端口接收数据，将数据插入以跳跃表为主结构的对应链表中。在网联自动驾驶车辆离开路侧设备控制区域时，路侧设备在感知后将与该车辆对应的数据链表移动至非活跃数据区的非活跃链表。在非活跃数据总量达到阈值v时，路侧设备将非活跃链表中的数据存入硬盘。路侧设备每经过周期m，将当前跳跃表底层节点的最近数据提取备份至硬盘中的临时文件，并替换上一代版本的临时文件。当系统出现故障时，路侧设备借助硬盘备份的临时文件，将数据恢复至内存。
98.本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些组
件或所有组件可以被实施为由处理器，如数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于ram、rom、eeprom、闪存或其他存储器技术、cd-rom、数字多功能盘(dvd)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。