让现有设备升级支持智能网联系统——知易行难

在过去的几十年里，美国各城市的基础设施所有者和运营商(IOOs)见证了车辆流量的指数级增长。到2050年，美国城市人口占总人口的比例预计将从2010年的80.7%增长到89%。

如今，美国有超过300个城市的人口超过10万，更多城市面临严重交通拥堵的挑战。交通拥堵将对社区出行、燃料/能源消耗、交通/行人安全风险、车辆排放和生活质量等带来负面影响。

与此同时，创新的数据驱动技术相继被应用到交通管理行业，在应对一些挑战方面取得了巨大进展，也出现了很多先进的交通管理系统(ATMS)，如交通信号优化，自适应信号控制，智能网联车辆(C/AV)系统等，被证明在减少通勤时间和缓解拥堵方面非常有效。

而这些应用很大程度上依赖于路口设备的计算和通信，尤其是交通控制器的计算和通信能力。

随着越来越多基于先进技术的交通感知设备和交通管理系统上线，如何在现有的基础设施中有效地整合这些技术，并使其发挥作用和实用，这对于需要大量数据的C/AV（自动驾驶、智能网联）系统来说尤其重要，而这是一个经常被忽视的问题。尽管C/AV车辆的车端和路侧设备已取得长足的进步，但要使自动驾驶成为现实，交通管理行业仍面临两个非常重大的挑战。如果以下情况出现，这些技术大多无法使用:1)交叉口管理的基本部分—交通控制器—没有为智能网联车辆上路准备好；或者交通管理当局没有把已安装的交通控制器升级为可支持智能网联车辆的交通控制设备。

目前有数千台2070ATC交通信号机（2070 ATC为一种硬件标准化、开放式结构的信号机，硬件和软件分离，甲方可以根据自己的需求依据标准来采购标准化功能的软件和相关硬件模块）正在使用中，对于绝大多数城市而言，一次性全部更换交通控制设备的成本太高了。因此，未来的挑战是提高现有交通控制基础设施特别是交叉口的通信和计算能力，为了利用新的数据驱动解决方案，交通信号控制机必须能够管理来自传统交通感知数据以及大量新技术传感器（基于车辆和基础设施）采集到的交通数据，包括那些已有的以及未来可能出现的。

当智能网联汽车规模上路后，他们可以帮助实时感知和预测整个交通环境，这些新数据源的出现，将对交通控制优化带来更多可能。但同时，交通控制器能够做出更明智的决策，并具备充足的计算能力。

但有个问题仍然存在——即如何升级数千台2070ATC交通控制机？这些设备最初设计时，并没有支持智能网联应用所需要的高级通信和计算要求。

相位、配时信息传递给网联汽车是智能网联系统的重要功能。

通信技术的进步，帮助创建了一个更广泛的ITS生态系统，包括V2X在内，智能网联系统已成为ITS框架的重要组成部分。在V2X环境下，联网车辆可以通过DSRC或其他无线通信网络技术，与其他车辆和基础设施即时、同时通信。而来自智能网联车辆的数据，可提供更完整的车辆状态或态势感知，包括位置、速度、轨迹和其他车辆位置信息。随着智能网联汽车数量不断增长，成千上万的网联汽车对交通数据采集、分析的方式方法将带来重大改变。

让现有2070ATC交通控制设备能够处理V2X系统所需的通信和计算需求，最具成本效益的方法是升级2070ATC信号控制机，使之支持接入智能网联系统的数据。虽然理论上听起来很简单，但在实际应用中却是相当复杂的。正如预期的那样，在将C/AV-ready交通控制软件迁移到不同的交通控制设备和平台时就遇到了一些问题。

就本文而言，软件迁移（porting）活动主要集中在采用e300 PowerPC处理器的2070-1CCPU 模块上，该平台构成了交通控制器的现有安装基础。

将C/AV-ready交通控制软件迁移到2070交通控制平台的主要问题涉及：1)控制卡；2) Linux O/S版本；3)驱动程序版本。由于其他制造商的设备驱动程序都绑定到特定的O/S版本，因此所涉及的数据空间和接入过程减少到两个维度：1)控制器；2) O/S版本。通过成功接入和测试新控制器软件，就可以更仔细地了解控制平台和制造商之间的功能差异，以及如何解决这些差异，以成功植入C/AV-ready交通控制软件。

 不同的控制平台

软件升级工作以设计验收测试(DAT)为中心完成，在第三方交通控制平台上运行，以确定控制存在差异的区域。然后修改DAT测试，使其在测试控制器上正确运行。这项工作是与使用交通控制平台的州交通运输管理部门一同参与完成。

其目标是用C/AV-ready交通控制软件更新升级已安装的来自不同制造商和平台的2070交通控制设备。测试的设备包含多个制造商和操作系统，基本涵盖了美国各地交叉路口安装的2070控制设备类型。

2070系列信号机的C/AV-ready交通控制软件部署测试包括如下操作系统：

Installed Controller OS Platforms

Linux 2.6.9

Linux 2.6.34

Linux 3.4.33+

Linux 3.14

每一个DAT测试都被设计用来验证是否符合ATC5.2版本标准的规范。在某些情况下，规范中的歧义被发现，而不是不符合规范。

在本文的基础上，软件植入工作以DAT测试为中心，这些测试在第三方交通控制平台上运行，以确定控制存在差异的区域。然后修改DAT测试，使其在测试控制平台上正确运行。控制设备之间的功能差异相对较小，但在解决之前足以导致智能网联软件故障，而许多差异导致DAT测试失败。然而，就目前的情况而言，测试中出现差异的功能并没有被C/AV-ready交通控制软件使用。

对于所有ATC控制器，计时钟应该与电力线频率同步，并且应该能够像预期的那样从设备驱动程序[/dev/tod]产生‘时钟信号。在所有情况下，都应确认测试控制设备通过了实时测试。ATC6.25版本标准B.7节对/dev/tod设备节点有要求。该要求不在ATC 5.2b旧版标准中。

控制器支持的时钟要求如下：

•Linux 2.6.34和3.4.33

O /dev/tod - absent

O ‘tick’ signal – should be available from CLOCK_MONOTONIC with Posix

•Linux 3.14

O /dev/tod - status unknown

O ' tick 'signal-should be available from CLOCK_MONOTONIC

O ' tick 'signa-may be available if/dev/tod is present

2070信号机箱的前面板设计为串行终端，使用串行端口设备[/dev/sp6]可访问面板。此测试需要验证发送命令、读取响应以及向用户呈现合理易读输出的能力。由于机箱前面板独立于主控板卡，本测试说明了控制器之间的端口处理差异。在所有情况下，测试的命令和显示功能正常。但有一个显著的区别是，运行Linux 3.4.33的控制器将无法正确响应来自前面板的指令，直到在DAT测试中“读取延迟”增加了大约50%，从120毫秒增加到180毫秒。根本原因是CPU速度、UART性能、端口配置、时钟粒度、O/S效率、O/S线程调度还是其他原因尚不清楚。

根据ATC 5.2标准，O/S和应用程序存储空间要求为6 MB，在ATC 6.25下，这增加到16 MB。所有系统满足ATC 5.2总存储规范，这个存储空间足够承智能网联支持软件的植入测试，并提供其正确功能。

Linux 2.6.x操作系统版本在交通控制领域的使用时间不到10年，嵌入式FAT文件系统支持可能包括FAT16和FAT32，尽管规范是FAT16。目前，还应支持COTS USB存储设备，而不仅仅是2GB以下的设备。请注意，“自动安装”不是ATC的要求，ATC 6.25中规定的启动时间除外。

 虽然C/AV技术已证明其在提高交通流效率、增强交通安全性、降低燃料消耗和减少车辆排放方面的潜力，但它也揭示了升级现有交通基础设施技术的必要性。基于V2X的通信和计算需求以及新的传感器数据给交通控制带来了巨大压力。

到目前为止，交通基础设施运营管理单位面临用新的、支持智能网联功能的交通控制器取代现有交通控制器的挑战，以适应和实施CAV系统的需求。随着传统车辆、半自动驾驶车辆和自动车辆在同一道路上行驶，且会延续很长时间，这一前景变得更加复杂。幸运的是，有一种方法可以升级现有2070控制设备的能力，以处理V2X系统所需的通信和计算能力扩容。作为持续开发的一部分，通过在制造商和操作平台之间植入智能网联支持软件来升级交通控制设备，这有助于为交通基础设施运营管理单位提供成本效益高的网联路侧设备解决方案。