自然驾驶数据采集系统架构

一种用于自然驾驶数据采集与存储的灵活系统架构

摘要

智能交通系统的创新依赖于对高质量数据的分析。本文阐述了我们数据管理基础设施背后的设计原则。这些原则强调灵活性和可维护性。通过将代码分解为可在多个独立进程上运行的模块化设计来实现这一目标。基于发布‐订阅网络的消息传递支持进程间通信，并促进数据驱动的执行。遵循这些原则，可以实现对新的感知模式和算法进行快速原型开发和实验。我们将所提出架构所依赖的通信库与几种流行的通信库进行了比较。系统中设计的特性使其具有去中心式、容错性强，并且易于在多台机器上扩展且仅需最小配置。使用所提出架构编写的代码紧凑、透明且易于维护。实验表明，与替代的通信库相比，我们所提出的架构具有高性能。

索引术语 —智能交通系统，自然驾驶数据，数据采集，数据存储，可视化，通信，LCM，ZMQ，RabbitMQ，ROS。

一、引言

RESEARCH 推动了智能交通系统（ITS）的创新。细致的观察、设计和测试使这项研究得以推进。为了确保这一进展富有成效，工程师和研究人员需要能够获取高质量的数据。因此，可靠且灵活的数据采集、存储和分析方法对于推动创新至关重要。

维护数据基础设施困难且耗时。随着数据系统在规模和复杂性上的增长，管理系统的资源消耗越来越大，且更容易发生故障。开发用于读取、处理和存储新感知模式的算法或软件可能成为一项繁重且高风险的任务。某些算法或感知模态可能会被证明是有用的，并将被集成到系统中。而其他一些可能仅在实验投入的努力上带来很小的回报。在最坏的情况下，某个算法或传感器将无法提供任何有用信息，最终将被完全从系统中移除。

本文的主要重点是数据采集。本文提出的数据管理基础设施旨在促进研究。在研究环境中，频繁地对新传感器和算法进行实验是很常见的。减轻在持续开发系统中的软硬件集成负担，可使工程师和科学家将精力集中于研究和快速原型开发。这一考虑强调了设计应具备灵活、可维护和可靠的特性。

本文的主要贡献是一种用于采集自然驾驶数据的软硬件设计策略。我们的数据管理基础设施的设计概览如图1所示。系统架构分为两大类：车载数据采集和非车载数据采集。车载数据采集系统如图1左侧所示。来自车辆传感器的数据由车载计算机自动记录。在车载计算机上运行的任何进程都可以访问或生成数据广播。非车载数据采集系统如图1右侧所示。外部基础设施能够opportunistic地从车辆中获取数据，并将记录插入中央数据库，以便后续的可视化和分析。车载和非车载系统相结合，由于不依赖人工操作员，成为积累大数据集的有效方法。

本文的其余部分结构如下。第二节讨论智能交通系统数据采集系统的相关工作。第三节中，我们提出了一种用于智能交通系统应用中数据采集的通用软件架构。第四至第六节描述了我们的车载和非车载数据采集系统。第七节简要介绍了如何对这些系统采集的数据进行可视化。第八节对我们的系统进行了评估。最后，第九节给出了我们的结论。

II. 相关工作

之前的研究项目已经开发出用于数据采集、存储、分析和可视化的复杂机制。这些系统的容量和灵活性使研究人员能够拓展智能交通系统的边界，并开展前沿研究。notable的例子包括贝尔塔·本茨[1]，这是一辆能够在城市交通中自主运行的汽车，以及DARPA城市[2]和大奖赛[3]挑战赛的参赛者。

除了单车系统外，还开展了许多大规模的车对车（V2V）试验。这些试验的重点并非自动驾驶，而是研究自然驾驶数据[4]的采集，并评估车对车（V2V）技术[5]。

此外，已对车辆队列的大数据进行分析，以从出租车获取的轨迹数据[6],[7]中提取出行行为、时间关系和出行分布的模式。

尽管之前的研究项目克服了维护数据基础设施的挑战，但其成功背后的战略常常被忽视。记录这些平台的出版物通常仅提供系统设计的高层概述——包括传感载荷、感知例程、任务规划策略和路径管理等主题。对于支持日志记录、处理、分析和数据可视化的架构，则很少提供详细信息。

对于正在开发新系统的研究团队而言，了解现有系统的设计将有助于确保采用成功的数据采集、存储、分析和可视化策略。据作者所知，目前尚无论文专门探讨智能交通系统领域实验工作这一重要方面。本文填补了文献中的这一空白，并记录了我们数据管理系统核心功能背后架构——采集、存储、分析和可视化。通过讨论我们方法背后的设计与理念，我们希望让其他人能够从我们积累的经验中受益。

III. 软件架构

开发用于管理并发和复杂任务的软件既耗时又困难。为了确保系统的成功和长期可用性，软件必须具备可扩展性、易于维护且可靠。在本节中，我们提出一种适用于智能交通系统应用的数据读取、处理和存储的软件架构。

所提出的软件架构旨在强调灵活性、可维护性和可扩展性。该系统能够在无需对代码库进行大规模修改的情况下添加新传感器和算法，使其成为研究和开发的有效工具。

软件设计哲学基于两个关键概念：发布‐订阅范式和进程间通信。第三节‐A 阐述了发布‐订阅范式作为编写松散耦合、可维护代码的方法的动机。第三节‐B 展示了如何利用进程间通信使系统高效且容错。

A. 发布-订阅

通过将软件分解为功能单元，可以独立地开发和维护小段代码。这些单元可以通过定义信息如何从一个单元传递到另一个单元来实现松散耦合。我们通过使用发布‐订阅范式来实现松散耦合。发布‐订阅范式是一种在对象之间传输数据的设计模式。被称为发布者的对象可以通过发出“发布”事件来提供数据。其他被称为订阅者的对象可以通过将回调函数订阅到发布事件来接收数据。

为了使发布‐订阅范式有效运行，订阅者必须知道如何通过回调解释接收到的数据。这是通过为系统使用的每种数据类型定义格式来实现的。这些格式称为消息。生成发布事件的对象只能将其订阅者传递一种消息类型。遵循此限制，订阅者通过向发布者注册回调，即表示其将接收特定的消息类型。尽管发布事件仅限于一种消息类型，但一个对象可以托管任意数量的不同发布事件。在系统中传递的消息均继承自基础消息类。继承可确保所有消息格式正确并包含公共属性。定义新的消息类型只需继承基础消息类并指定该消息将包含哪些数据字段，这成为一个简单的任务。

采用发布‐订阅范式的优势在于，发布者无需考虑数据发布后将如何被处理。同样，订阅者也无需关心数据在发布前是如何生成的。除了促进松散耦合和可重用的对象外，发布‐订阅范式还支持事件驱动软件。用于读取传感器信息的软件可以通过发布事件使数据可用，并驱动系统内的活动。设计用于处理传感器数据的回调函数仅在数据通过发布事件变得可用后才会执行。

B. 进程间通信

第三节‐A中描述的发布‐订阅范式允许多个松散耦合的对象在单个进程中共享数据。在复杂系统中，将所有功能集中于单个进程中是不可取的，因为这会形成难以诊断的单点故障。通过将系统划分为定义明确的异步模块，系统可以实现分布式架构。

由于进程在独立的内存空间中运行，发布‐订阅机制（第三节‐A）无法直接应用。必须使用进程间通信将发布‐订阅范式从对象级别扩展到进程级别。为了传输数据，进程需要共享一种通用的通信机制。任何支持多对多数据分发（如多播[8]或星型拓扑[9],[10]）的通信库均可使用。在我们提出的框架中，采用了IPv6组播。该传输机制将在第六节中进行更详细的讨论。

使用进程间通信将进程连接在一起，实现了系统功能的去中心化。这些进程可以在异构的主机、硬件架构、操作系统和编程语言上运行。将系统分布到多个进程中，还可以使软件充分利用越来越多的处理核心，实现代码的并发执行。除了高效之外，多进程策略还增强了系统的完整性。由于每个进程都被隔离并分配了独立的资源，如果某个进程发生故障，不会导致整个系统崩溃。同样，一个资源占用较多的进程也不会阻塞或妨碍其他进程公平地访问系统资源。

通信网络的拓扑结构设计为每种消息类型都关联一个特定的统一资源标识符（URI）。同样，这种一对一的限制使得消息传递策略更加明确。通过监听特定URI上的广播，监听器即表明其将接收某种特定类型的消息。尽管 URI与消息类型之间存在一对一映射，但广播者与监听器之间可以存在多对多关系。多个进程可以向同一个URI发布广播，同时也有多个进程可以监听这些广播。能够订阅和发布数据到一组有限的已知URI，使得在广播者与监听器之间建立多对多关系变得简单且可维护。简化复杂数据流量网络的构建能力，有助于推动具备采集大数据能力的系统的发展。

在一个包含多种消息类型的系统中，进程需要识别可用的消息以及如何定位这些消息。网络拓扑通过消息规范提供给系统，该规范将消息类型映射到统一资源标识符。希望参与并符合网络流量要求的进程必须遵守该规范。为了消除多对多拓扑中消息生成位置的歧义，广播者和监听器可以在传输过程中使用topics来过滤消息。例如，在配备前向和后向摄像头的车辆中，图像消息可以通过将广播分别与“forward”和“rear”主题关联来区分。

进程间通信策略如图2所示。图中的每个模块代表一个独立进程。连接各进程的线条表示消息广播。如图所示，进程可以被添加到系统中或从系统中移除。例如，车辆速度可以通过控制器局域网（CAN）总线或车轮上的编码器提供。从一个数据源切换到另一个数据源对系统的其余部分是透明的。类似地，算法也可以透明地添加到系统中或从系统中移除。在图2最右侧，使用无迹卡尔曼滤波器（UKF）和扩展卡尔曼滤波器（EKF）并行生成状态估计。UKF和EKF的估计结果可以通过主题进行区分。通常情况下，只会运行一个针对特定车辆模型调优过的位置滤波器。

IV. 车载数据采集

车载数据采集使用第三节中描述的软件架构来执行。第四节A部分简要讨论了可用于日志记录的数据类型。用于运行我们的软件架构并记录传感器数据的车载计算机在第四节B部分中进行了讨论。日志记录系统的实现细节在第四节C部分中进行了讨论。

A. 传感器

现代高级驾驶辅助系统（ADAS）正在监控日益复杂的驾驶任务，并提供诸如车道偏离警告、自适应巡航控制和自动泊车等支持与功能。下一代高级驾驶辅助系统，例如检测行人[11], 推断驾驶员意图[12],[13] 以及高级碰撞避免系统[14],[15]，需要复杂的感知模式来收集实现其目标所需的数据。

开发下一代高级驾驶辅助系统将需要对多种可能全新的感知模式进行实验。其中一个

我们的研究车辆如图3所示，是具有多种感知模式的实验系统的示例。以下列表中列出的传感器在智能交通系统（ITS）研究项目中常见。
- 惯性测量单元（IMU）
- 全球导航卫星系统（GNSS）
- 激光雷达
- 雷达
- MobileEye
- CAN消息
- 专用短程通信（DSRC）无线电模块

聚合智能交通系统研究平台中常见的多种数据源，促使需要设计一个系统来集中和记录车辆生成的所有传感器数据。第四节B部分所述的车载计算机满足了这一需求，并作为处理传感器数据的灵活中心节点。

B. 车载计算机

我们的研究车辆中的传感器数据在一台定制组装的车载计算机上进行记录和处理。该系统的硬件组件如图4所示。为简洁起见，我们将此硬件称为黑匣子。

黑匣子基于迷你ITX的x86主板，安装在加固型计算机机箱中。硬件选型旨在满足记录传感器数据、轻量处理和网络供应的设计标准。内部采用消费级组件，以降低成本、缩短供货周期，并便于根据计算需求增加进行升级。目前，黑匣子配备有英特尔G3420处理器和4GB内存。数据被记录到固态硬盘上。

网络连接由千兆交换机和WiFi USB适配器提供。车对车（V2V）和车对基础设施（V2I）通信由Cohda Mk4 DSRC无线电模块提供。黑匣子提供的网络功能使其既可以作为协调网络流量的中心节点，也可以作为联网计算机系统的一部分。

C. 数据记录

数据分析对于理解自然驾驶场景的特征和开发新算法至关重要。因此，收集高质量数据是推动智能交通系统应用研究和进步的基础。该黑匣子的主要目标之一就是提供一种数据记录机制。这是通过第三节中描述的灵活软件架构实现的。

如第三节‐B所述，进程可以识别系统中有哪些消息可用以及如何定位这些消息。这使得任何进程都能够访问整个系统的网络流量。由于消息类型与统一资源标识符之间存在一对一映射，因此通过为系统中的每个统一资源标识符订阅一个监听器，便可实时记录所有网络流量。当接收到一条消息时，监听器会将自日志记录开始以来经过的时间、广播主题和消息负载记录到一个纯文本文件中。该策略会在系统内每种广播的消息类型各自生成一个日志文件。用于记录网络流量的进程在图2中显示为底部的模块。

高频率或大容量数据（如惯性测量和图像）可能导致日志文件大小迅速增加。大型数据文件不利于机会式数据采集，因为车辆可能仅在路侧单元（RSU）覆盖范围内停留几秒钟，无法完成大型日志文件的传输。为了使日志文件适合机会式采集，可以通过数据条目数量、时间或两者结合的方式对日志文件进行分割。机会式数据采集的基础设施在第五节A部分中描述。

为防止记录无意义的数据，日志记录系统仅在发动机启动时开始运行。同样，当发动机关闭时，日志记录系统也会终止。这种自动记录系统在促进资源高效利用的同时，也更加便捷，因为它不依赖于人工操作员。数据集由发动机启动和发动机关闭事件定义。每个数据集都存储在一个新创建的带时间戳的目录中。

V. 车外数据采集

第IV节中描述的车载数据采集系统能够自动记录复杂的传感器数据有效载荷。尽管这些系统可用于车辆试验，但其应用受到人工操作员需要定期手动检索系统所记录数据文件的限制。人工干预不利于积累大数据。

本节描述了车辆外部的附加基础设施，这些设施使系统能够自动从车载数据采集系统中采集数据。同样，第三节中描述的软件架构被用作该系统的骨干。第五节A部分描述了如何从车载数据采集系统中自动采集数据。第五节‐B描述了所采集的数据如何存储在中央数据库中。

A. 机会式数据采集

我们系统的一个重要特征是，车外数据采集系统能够收集由车载数据采集系统记录的数据。我们的车外数据采集系统在配备专用短程通信（DSRC）并连接到中央数据库的路侧单元上实现。一旦车辆能够通过专用短程通信（DSRC）连接到路侧单元，数据便可传输至中央数据库。我们已在采矿及采矿安全领域展示了这种方法的价值[16],[17]，并将其类似方法应用于智能交通系统。

该进程的序列图如图5所示。为了避免在DSRC无线电与路侧单元建立通信时频繁地在车载计算机上创建和拆除路由，该序列由DSRC无线电发起并控制。第一步是确定是否可以通过路侧单元与数据库服务器建立通信。DSRC单元会周期性地向数据库服务器发送ping请求，并监听响应。如果收到响应，则开始数据采集进程。这是通过在车载计算机和数据库服务器之间建立一个ssh隧道来实现的。选择此设计是因为DSRC无线电already需要通过ssh连接到车载计算机以启动文件传输，因此可以将隧道设置集成到该进程中。隧道建立后，车载计算机运行rsync来传输文件。成功传输的文件将被从车载计算机中删除。这消除了定期维护以确保车载计算机上有适当磁盘空间的需求。数据库服务器会定期轮询存储上传的日志文件的目录，并使用第五节‐B中描述的方法处理任何新文件。

由于车载数据采集系统将不同的消息类型记录在单独的文件中，因此采集系统可以配置为优先处理某些消息类型。这样可以在尊重车对基础设施（V2I）网络带宽限制的同时，从车辆中恢复信息。消息优先级可根据特定部署的需求进行配置。例如，在实时监控应用中，位置和速度等状态信息可被优先于占用带宽较多的摄像头数据。

这种架构的一个自然结果是，随着路侧单元数量的增加，车辆记录数据与数据在数据库中可用之间的时间延迟会减少。如果基础设施的部署使得特定车辆始终与路侧单元保持连接，则车辆的数据将能够实时获取，而无需对系统的根本底层配置进行任何更改。这为实时交通监控与管理提供了可能。

B. 数据库

数据库服务器拥有一个PostgreSQL/PostGIS数据库。当日志文件从车辆中收集后，会被解析并存储到数据库中。日志文件也会保留在服务器上以用于备份。数据库中的地理信息系统（GIS）扩展功能使得基于地理空间基础的数据查询比在日志文件中搜索简单得多。

原始数据中的每条消息都以一种直接的方式进行处理。如果消息包含地理空间信息，则从该消息中提取并组合成一个单一的PostGIS几何实体。此类消息包括全球导航卫星系统（GNSS）消息、接收到的专用短程通信基本安全消息（BSM）以及来自位置滤波器（如无迹卡尔曼滤波器）的消息。由于PostgreSQL能够将JSON作为原生类型处理，并且消息被存储为关联数组，因此非地理空间数据被转换为JSON表示形式，并直接注入数据库。这种方法的优势在于，带有可选字段的消息可以在数据库中进行存储、索引和查询。这提供了既能存储半结构化数据，又能利用SQL索引和地理空间查询能力的综合优势。正是这种灵活性，使得第七节中讨论的报告与可视化成为可能。

数据从车辆传输到数据库的方式支持使用分片技术来实现负载均衡和可扩展性。例如，可以在不同站点建立多个数据库实例，每个数据库连接到本地路侧单元。通过仅连接少量具有大量车辆交通（因此产生大量数据下载）的路侧单元，即可实现对单个数据库的负载均衡。然后，这些数据库分片可以通过成熟的数据库分片工具将其数据聚合到单一实例中。因此，该系统的可扩展性仅受限于数据库后端，而不是V2I网络本身。[18]中讨论了来自车辆系统的大数据存储、复制和负载均衡的先进技术，这些技术可应用于我们的架构。

VI. 通信

第三节中讨论的软件架构以及第四节和第五节中讨论的硬件需要明确定义的通信协议。在第六节A部分，我们提议使用IPv6 UDP组播作为网络传输机制。在第六节B部分，我们讨论如何配置网络以促进设备之间的IPv6 UDP组播。

A. 软件

第三节‐B中描述的进程间通信架构需要一种能够支持多对多数据分发的网络传输。我们为进程间通信所采用的传输机制是IPv6 UDP组播。该设计与轻量级通信和编组（LCM）[8]库类似，后者使用IPv4 UDP组播。之所以优先选择IPv6，是因为与IPv4相比，IPv6大大简化了组播组和路由的创建。

在软件架构中，每种消息类型都关联到一个唯一的组播组。发布者和订阅者可以通过订阅组播组来开始发送或接收消息。以这种方式使用组播组具有优势，因为是否在网络中转发消息的决策对高层软件架构是透明的。这些决策由网络中的交换机和路由器在网络层面进行处理。

由于我们的传输机制依赖UDP而非TCP连接，因此无法保证消息传递或消息顺序。UDP也无法传输大消息，例如大型图像。为了处理大有效载荷，已实现了一种分拆和编组系统。同样，这种方法类似于LCM。

B. 配置

为了使网络对软件架构尽可能透明，选择了一种便于配置和服务发现的寻址方案。典型的车载数据采集系统和路侧单元节点的寻址方案如图6所示，并在表I中进行了总结。

每个车载数据采集系统包含三个主要组件，如图4和图6左侧所示。这些组件是以太网交换机、车载计算机和专用短程通信无线电模块。以太网连接在2001:db8:0:0nnn::/64子网中分配地址——其中nnn是设备单元编号。车载计算机分配的静态IP地址为2001:db8:0:0nnn::1/64，DSRC无线电为2001:db8:0:0nnn::2/64。

通过以太网交换机连接到网络的任何设备都可以根据在车载计算机上运行的radvd守护进程所广播的前缀自动配置其IP地址。该radvd守护进程还在WiFi接口上广播2001:db8:0:1nnn::/64前缀。系统提供通往2001:db8:0:0nnn::/64和2001:db8:0::/64子网的路由。使得连接WiFi的设备能够直接与DSRC无线电通信。DSRC无线电通过与其他DSRC节点建立自组织网络连接，实现车对车（V2V）和车对基础设施通信功能。DSRC无线电表现得像一个标准的网络接口，并被分配了2001:db8:0:2nnn::2/64地址。

路侧单元（RSU）的物理设备较为简单，但每个接口的网络配置稍显复杂。DSRC无线电单元在DSRC接口上具有相同的地址，同时还通过radvd广播前缀，供连接到它的其他DSRC节点使用。数据库服务器位于地址2001:db8:0:3nnn::3/64和2001:db8:0:3000::3/64，其中nnn为服务器编号。

为了使网络更易于使用，车载数据采集系统和路侧单元中的每个网络接口都被分配一个任播地址。这意味着这些地址在所有设备之间共享。最先接收到某个地址请求的设备将进行响应。车载计算机被分配任播地址2001:db8::1/64，DSRC无线电被分配2001:db8::2/64，数据库服务器被分配2001:db8::3/64。其结果是，连接到网络的设备无需知道具体的设备编号。例如，通过连接到2001:db8::1/64，设备将连接到最近的车载计算机。数据库服务器共享任播地址2001:db8:0:3000::3/64和2001:db8::3/64。

表I IPv6地址方案摘要

VII. 数据可视化

第三节讨论的软件架构以及第四节和第五节讨论的硬件允许大量数据从车辆中自动采集的数据。长时间收集多辆车辆的数据有可能积累海量数据。可视化这些大数据是在提取有用信息之前的重要初步步骤。

我们的架构灵活，并提供了多种数据可视化方式。本文所述系统支持数据的实时显示，相关内容在第七节A部分中讨论。用于可视化数据的车外方法在第七节B部分中讨论。

A. 车载可视化

任何具有连接无线网络能力的移动设备都可以访问黑匣子内的数据广播。移动设备可以通过黑匣子提供的WiFi网络与其连接。尽管此功能可用于设备间的信息交换，但已连接的移动设备需要额外的软件来读取和显示数据广播。为了避免让移动设备依赖专用软件，摘要数据通过每个黑匣子上托管的网站提供。一旦接入黑匣子网络，移动设备仅需一个浏览器即可查看实时系统更新。

黑匣子还承载了一个安装了GIS扩展的PostgreSQL数据库[19][20]。这使得OpenStreetMap（OSM）数据可以存储在车辆本地，用于本地区域。这些数据为更广泛的软件生态系统提供了丰富的上下文信息，例如当前街道的名称、限速或到下一个交叉口的距离。

图7展示了一个平板设备连接到车辆WiFi网络的示例。该设备已访问本地托管的网站，该网站提供车辆的当前位置、周围的OSM切片以及通过DSRC通信的入侵车辆信息。此类可视化使研究人员能够在多车实地试验中协调操作，并确认数据被正确记录。实时可视化还为向驾驶员提供信息以提高态势感知能力奠定了基础。可视化内容可包括系统识别出的任何威胁信息，例如碰撞风险增加或其他车辆的异常行为。

B. 车外可视化

有多种车外可视化方法可供选择。数据可以像实时系统一样进行回放，如第七节‐B1部分所述。或者，可以从数据库中挖掘大量数据，为二维可视化提供丰富来源，如第七节‐B2部分所述。第七节‐B3部分描述了如何利用历史数据来模拟交通环境。

1) 回放

历史数据的实时回放提供了一种可重复的机制，用于基于真实数据的人工环境中测试新算法。在此环境中测试算法，可以在进行昂贵的实地试验和部署之前，利用历史数据对其进行开发和验证。

使用进程间通信（第三节‐B）在进程之间传输数据具有一个有用的特性：对于接收消息的进程而言，实时数据和回放数据之间没有区别。数据消费者无法识别数据是实时生成的，还是历史数据正在被重新注入系统。为了回放数据，可以为系统中的每种消息类型创建一个广播器。然后从日志文件（第四节C部分）或数据库（第五节‐B）中读取记录的消息，并通过相应的广播器发布。回放期间广播的顺序和时序结构旨在重现日志记录期间最初观察到的通信流量。

2) 数据库查询

随着时间的推移，数据库能够从多辆车辆自动获取大量数据。将数据集中存储在一个位置，可以针对单个驾驶员、驾驶员类型、地理空间位置或整个交通网络进行数据库查询。通过所收集的丰富数据，可以报告交通流量和拥堵情况、交通规则违规热点、险些碰撞以及网络效率等信息。

地理空间参考数据可以轻松地通过俯视热力图进行报告，如图8所示。即使是更复杂的查询，例如选择所有车辆在交通信号灯50米范围内停止的数据，也易于实现。该查询的结果如图9所示。

3) 仿真

传统的交通数据可视化通常在地理空间或时间域中进行。彩色地图和时序图是常见的表示方式在这两个时间域[21]中。一种分析此信息的替代方法是将地理空间和时间域统一到一个沉浸式三维环境中。以这种方式可视化数据，为人们理解交通交互提供了一种自然且直观的方法。

图10展示了我们在3D引擎中重放日志数据方面所做的工作。图11展示了可作为仿真输入的各种数据源。日志数据与算法和智能体模型相结合，以生成模拟环境。为了增加真实感，向场景中添加了地理空间信息和街景图像。多种3D游戏引擎能够实现这种可视化策略，并已在文献中讨论过[22]。在我们的工作中，使用了Unity3D。

精确的模拟环境是一种有用的研究工具。在最基本层面上，模拟环境提供了一种从任意视角可视化记录数据的机制。例如，可以从场景中任何驾驶员或行人的视角查看数据。然而，模拟器的功能不仅限于重放记录的数据。未来的模拟器将能够运行包含模拟智能体的合成场景。为了逼真地描绘合成场景中的智能体，需要开发统计上精确的驾驶行为模型。随着大量自然驾驶数据的数据库被收集，这些模型将得以建立。创建合成交通场景的能力将使研究人员能够在安全且受控的环境中研究驾驶行为，而无需实地测试所需的高昂成本和资源。

VIII. 评估

我们所提出架构的基础是第三节中描述的软件范式以及第六节中描述的IPv6通信策略。第八节‐A部分包含了对我们所提出的软件架构与其他几种通信库的高层级比较。第八节‐B部分量化了我们的系统相对于其他通信库的性能。第八节‐C部分讨论了对我们的软件架构及其在研究中应用的更广泛评估。

A. 比较

我们系统设计的驱动因素是可扩展性、易于维护和可靠性。我们将系统的通信主干称为多进程通信库（MCL），并已将其公开发布[23]。在开发该软件之前，我们评估了LCM[8]、ZMQ[24]、机器人操作系统（ROS）以及RabbitMQ（RabbitMQ）[9]。表II展示了这些通信库之间关键差异的比较。这些通信库大致可分为两类：集中式和去中心式。

ROS和RabbitMQ的相似之处在于都需要一个中央服务来实现消息路由。这些架构的问题在于，中央服务会形成单点故障，可能导致系统内的通信中断。虽然添加新的进程或消息相对简单，但向系统中添加新节点需要额外的配置。每个加入网络的设备都需要知道消息规范以及中央服务的位置。在我们的软件架构中，节点加入网络仅需知晓消息规范，无需进行任何配置。通过将每种消息类型唯一地关联到一个组播地址，新节点只需加入网络即可参与通信。

ZMQ 是一个高性能通信库，提供类套接字接口用于传输和接收数据。我们的目标之一是实现一个支持多对多连接的通信系统。也就是说，多个广播器可以在网络上向多个接收者发布数据消费者。虽然ZMQ允许多个连接在特定套接字上监听数据，但只有一个进程可以绑定到套接字并发布数据。为了实现多对多拓扑、复杂网络，需要实现目录服务或代理。稳健地实现这些解决方案是一项具有挑战性的任务。

我们的系统与LCM最为相似。在LCM中，使用IPv4 UDP组播广播强类型消息。而在我们的架构中，使用IPv6 UDP组播广播弱类型消息。通过利用多播，这两个库在不存在单点故障的意义上都具有较强的鲁棒性。多播使得任何进程都可以监听或在特定地址上广播数据，而无需依赖代理或发现服务。如果某个特定进程阻塞，也不会影响其他进程之间的通信能力。两者之间的一个区别在于，我们的库能够传输弱类型消息，其中任何可序列化对象都可以被传输。尽管我们的软件允许定义包含必填字段的消息，但也支持动态创建和传输新字段。而在LCM中，消息是强类型的，无法动态地向消息中添加新字段。

通信库还可以根据用于传输数据的协议进行分类。ZMQ、ROS 和 RabbitMQ 使用 TCP 传输数据。MCL 和 LCM 使用 UDP 进行数据组播。TCP 是一种更可靠的协议，因为它能保证传输以及数据传递的顺序，而 UDP 则不能。另一方面，UDP 具有更低的延迟和无连接的传输模型。正是这种无连接的传输模型使得基于 UDP 的通信库能够以去中心化方式运行。

表II 通信库比较

B. 定量

我们的测试结构与在[8]中执行的测试类似。单个进程以不同速率发送ping消息。多个客户端进程接收ping消息，并将数据作为pong消息回传。最后一个进程用于记录所有网络流量。日志数据用于计算网络性能。

网络性能通过带宽和延迟来量化。传输带宽通过将观察到的已记录pings 数量与目标发送速率进行比较来计算，用于衡量软件以高频率发送数据的能力。接收带宽通过将观察到的已记录pongs 数量与目标ping 发送速率进行比较来计算，用于衡量软件以高频率接收数据的能力。请注意，接收速率受限于传输速率。在每个ping消息创建和传输时记录时间，在客户端接收到ping 消息并将数据复制到pong消息时也记录时间。这两个时间戳用于计算通过网络发送数据的延迟。

在以下测试中，ZMQ、LCM、ROS 和 RabbitMQ 与我们的系统进行了比较。为了确保各通信库的实现尽可能具有可比性，我们努力对每个通信库的测试代码进行了标准化。如前所述，我们系统设计的主要指导原则是快速原型开发和开发便捷性。基于这些考虑，我们选择的软件语言是Python。我们有意在性能上做出了权衡，放弃了像C++ 这样的编译型语言，以换取更高的开发便捷性。本节中讨论的测试均在Python 中进行。所呈现的结果在比较用于Python的通信库时是客观的。需要注意的是，不应将这些结果视为适用于每种库所有语言实现的绝对性能评价。

1) 本地主机

为了测试软件在多个进程下的可扩展性，单台机器上运行了一个ping服务器、一个日志记录进程以及1、3和6个pong客户端。每个ping空间和pong消息包含一千字节的有效载荷。结果是在10秒的测试窗口内取平均值。结果如图12所示。数据显示，我们的软件（MCL）在最多三个pong客户端的情况下，能够提供与LCM和ZMQ相当的带宽和延迟，同时在最多六个pong客户端时仍保持高性能选项。在所有场景中，MCL均优于RabbitMQ和ROS。

为了测试软件在消息大小方面的可扩展性，单台机器上运行了一个ping服务器、一个日志记录进程和三个pong客户端。每个ping和pong消息包含500、1500和3000字节的有效载荷。结果是在10秒的测试窗口内取平均值。结果如图13所示。数据显示，随着有效载荷大小的增加，所有通信库的实测收发带宽均有所提高。同样，MCL能够提供与ZMQ和LCM相当的带宽和延迟。随着消息大小的增加，除RabbitMQ外，所有方法的带宽趋于一致。

图12和图13显示，随着消息流量的增加，收发带宽与理想传输的偏差进一步加大。每秒发送的消息数可以通过向系统中引入更多pong客户端或减小消息负载的大小来增加。请注意，当消息负载减小时，需要传输更多的消息才能达到目标带宽。

在这些测试中，系统的瓶颈主要在于可用计算能力。测试是在一台配备Intel i7‐2640M处理器和8GB内存的消费级笔记本电脑上进行的。随着每秒发送的消息数增加，计算能力成为更稀缺的资源。消息的接收速度超过了处理速度。通信库实现上的差异开始影响其能够处理的通信量。

相反的情况也是如此。随着系统中消息数量的减少，通信库在很大程度上摆脱了其自身实现效率低下以及硬件限制的影响。这一点在图13(c)中可以明显看出，除RabbitMQ外，所有通信库能够提供类似的性能。这是通过以低频率传输大消息实现的。

结果表明，去中心式方法优于两种集中式方法。ROS和RabbitMQ都依赖于一个集中式进程来实现通信。这些中央进程会成为系统中的瓶颈。当系统容量达到上限时，这一点可以在ROS图表中观察到其趋于平缓的现象。去中心化架构通过允许直接通过套接字（ZMQ）或多播（MCL和LCM）通信。这使得去中心式策略更具可扩展性，因为它们能够将处理负载分布在多台机器上。

尽管ZMQ提供最高的带宽和最低的延迟，但它是最不灵活的架构。由于仅允许一个进程可以绑定到套接字并发布，每个发布pong消息的客户端必须打开一个全新且唯一的套接字。为了接收所有pong消息，一个新的进程需要知道如何连接到每个pong套接字。测试构建了一个简单的网络，其中客户端数量是预先已知的。这使得“硬编码”网络拓扑成为可能。在复杂且动态的网络中，这种简单的策略无法良好扩展。

测试表明，MCL能够以最小配置提供高带宽、低延迟和可扩展性的良好结合。从定性角度来看，使用MCL编写的测试代码比其他库更加紧凑。我们在第三节‐A中提倡的事件驱动架构使得透明代码只需几行即可编写完成。我们相信这有助于促进更易于调试、维护和扩展的代码。

2) 网络

为了测试软件在局域网上的效率，使用一个ping服务器和三个pong客户端进行了测试。之前测试中使用的笔记本电脑被用作服务器，以发送ping消息并记录网络流量。三个黑匣子（第四节B部分）客户端用于返回pong消息。所有计算机通过千兆交换机连接。pong客户端中的时钟与运行在ping服务器上的NTP服务器同步。对于ROS和RabbitMQ，中心进程托管在ping服务器上。每个ping和pong消息包含500字节的有效载荷。结果取10秒测试窗口的平均值。结果如图14所示，可与在单台机器上执行的相同测试[图13(a)]进行比较。

最显著的结果是，集中式通信库（ROS 和 RabbitMQ）无论是在单台机器上运行还是作为分布式网络的一部分运行，其性能表现相似。相反，去中心式方法（ZMQ、MCL 和 LCM）在分布式网络中运行时则具有显著优势。在分布式网络中，去中心式方法能够通过将处理负载分散到多台机器上的额外节点来分担处理负载。

通信库的延迟无法可靠地测量。尽管时钟通过NTP服务器进行了同步，但每个库仍能以一定的延迟发送数据小于NTP同步时钟中的抖动。与图12和图13中显示延迟不同，图14的最后一个子图显示了成功传输的数据的总百分比。这是通过计算接收到的pings和pongs数量与发送的pings和pongs数量之比来衡量的。

成功传输的数据总百分比表明，基于TCP的方法（ZMQ、ROS）优于基于UDP的方法（MCL、LCM）。一旦基于UDP的方法受到处理器限制，它们会通过丢包继续运行。虽然这能够实现较高的收发带宽，但也意味着大量数据丢失。由于TCP保证消息投递，因此消息不能被静默丢弃。这将网络流量交换量限制在处理器的容量范围内，导致收发带宽较低，但数据不会丢失。

C. 研究效用

我们团队在矿业中使用了类似的车载日志记录与数据采集架构，由此产生了一个公开的数据集，涵盖三年时间，涉及30辆车辆[25]。为了说明该数据集的规模，典型的一天数据包含车辆行驶总距离约3000公里。该数据集已被用于多种不同类型的分析，包括道路测绘[26],长期预测估计[27],故障检测[28]和行为[29]分析。据作者所知，这是目前研究人员可获取的最全面的协作式智能交通系统数据集之一。

本文提出的架构改进了我们之前的数据采集框架。它更加自动、可扩展、灵活和可靠的。这使其成为快速原型开发以及试验新传感器和算法的理想环境。我们所提出的架构能够自动收集的数据量也使其成为采集大数据的理想环境。

本文提出的系统已在我们的测试场地部署。两辆研究车辆配备了数据采集系统（第四节）。校园内设有两个路侧单元（第五节）。其中一个路侧单元位于我们经常驾车经过的位置，这使我们能够测试实时流媒体功能。第二个路侧单元位于车辆停放区附近，确保驾驶结束后所有数据都能自动上传。数据收集的进程非常简单：只需驾驶车辆，并在驾驶结束后将其停放在指定停车区域即可。随后可通过查询我们的数据库来访问数据。这种低干预方法极大地简化了我们进行实验的能力。

该系统在提交本文时已连续运行并自动采集数据达一年之久。尽管我们当前部署的运行时间较短，且涉及的车辆较少，但目前已自动记录了数百万条数据。在如此短的时间内，所提出的系统架构已满足其设计要求。由于具备自动采集基础设施，数据收集与挖掘变得十分简单。软件的灵活性也允许新算法被集成到系统中。因此，我们能够集中精力开展关于驾驶员行为[30],[31]和导航滤波器一致性[32]的研究。

IX. 结论

本文提出了一种用于智能交通系统应用中数据采集、存储、处理和可视化的模块化架构。该设计基于发布‐订阅范式，采用IPv6组播实现进程间通信。该策略允许将代码分解为模块化设计，可在多个独立进程中运行。通过发布‐订阅网络进行消息传递，使得通信能够在单台计算机内、多台计算机之间以及运行不同编程语言的异构平台之间透明地进行。

所描述的软件架构可用于车载数据采集和非车载数据采集。车载数据采集系统会自动将车辆数据流记录到日志文件中。当处于路侧单元（RSU）范围内时，车载数据采集系统能够通过DSRC无线电自动将日志文件上传至中央服务器。日志文件上传后，会被插入数据库中。该系统的软件和硬件设计相结合，可实现从车辆记录复杂数据并将其插入数据库，而无需人工干预。这种设计的自动化特性使系统非常适合收集大数据。

与ZMQ、LCM、ROS和RabbitMQ相比，我们提出的架构在高带宽和低延迟传输方面提供了良好结合。由于系统设计为去中心式，能够容错性强，并且易于扩展到多台机器，且只需最小配置。我们认为，本架构所倡导的设计范式有助于鼓励透明、可扩展且易于维护的代码开发。