【DDS 自动驾驶】如何设计自动驾驶汽车使其在现实世界表现出良好性能
【关键字】DDS 自动驾驶 无人驾驶 数据分发服务 人工智能
在当前的汽车市场，自动驾驶汽车的研发面临着巨大的风险和不确定性。由于尚未建立成熟的商业模式，而且技术也在不断开发和完善过程中，行业巨头们正在尝试探索着不同的发展方向。大多数传统的汽车公司正在将重心从硬件转移到软件，在此进程中不断探索新的业务模式，意图创建自己的解决方案。
但是，自治系统中的软件是一个很复杂的问题。时至今日，汽车越来越成为由相互连接的计算机组成的网络，这里所说的计算机既包括了功能强大的CPU，也包括低端的微控制器。它们中的每一个都处理数据、做出决策和/或争抢资源。当图像和激光雷达处理、传感器信息融合、驾驶控制和远程遥控等任务协同工作时，交互的数量和系统的复杂度将同步大幅增加。
为了解决这一日益增长的问题，必须实现这样一种技术：它能够实时共享数据并处理具有不同优先级、来源和目的的大量数据，而且具有相当的健壮性，因为一次故障的结果很可能导致一起交通事故。对于汽车厂商来说，在如此苛刻的安全性要求下完成软件系统的构建，是整个软件化进程中一项重要的挑战。面对一系列可能存在的需求，并非所有的软件解决方案都能够胜任这一任务。那么，哪些解决方案能够真正满足未来自动驾驶汽车制造的广泛需求呢？
四种可选的技术途径
为了尽可能的降低风险，自动驾驶汽车的开发商需要快速创新并适应不断变化的市场条件和技术发展。通过在开发过程的早期选择正确的软件平台实施策略，企业可以确保他们拥有正确的基础以保持竞争优势。有以下四种技术途径可供选择：
方案1
云和企业级信息化技术。此类技术一般用于大型系统，也能够适用于远程遥控等应用场景，但并未针对需要实时响应的自治系统进行优化。举例来说，用激光雷达检测障碍物是一个典型的自动驾驶场景，在这种情况下，我们需要尽量缩短激光雷达设备和障碍物检测应用程序之间的延迟时间。如果使用基于云的解决方案，应用之间的通信延迟和需要在远程链路上双向传输的数据量都将很可观，而这些应用可能原本就运行在同一个ECU中，上述资源都是不必要的浪费。此外，大多数此类技术架构中都存在服务器或代理节点，这会导致单点故障，可能对系统的健壮性造成巨大风险。
方案2
从头建立一套自己的解决方案。汽车制造商有时会认为他们的数据交换要求非常特殊，依靠现成的解决方案无法解决这些问题。他们确实需要多种非常特殊的数据流，例如制动信息/报警信息等高优先级的小包数据、在多个地区运行所需的大量流数据、命令和响应信息、以及仅在给定条件下才需要获取的数据等。但这些通信场景真的独特到需要专门去实现吗？实际上，这些场景不仅是汽车电子行业的特殊需求，在类似飞机，火车，航空航天和国防车辆等任何现实世界的自治系统中都是常见的。所以，从头创建一套数据连接解决方案，意味着要花费大量资源，解决的问题却是别人早已解决过的问题，而且这些功能并非公司产品的核心价值。通常情况下，汽车公司的核心价值所在并不是如何集成软件系统或如何实现通信性能，而是提供更多的高级算法和应用功能；当然只有当基础平台能够及时提供必要的数据时，这些独特的算法和功能才能够真正发挥作用。
方案3
选择一种新的汽车平台，例如AUTOSAR Adaptive，ROS 2，Apollo等，并围绕它们构建自己的系统。尽管其中一些是新技术或面向特定市场的技术，但它们已成为汽车生态系统的一部分，可以为成千上万使用它们的人提供有用的资源。例如，如果您想实现视频、普通雷达和激光雷达的可视化，在ROS中能够很方便的找到相应的图形化程序。当然，选用上述哪种平台作为最佳方案，也取决于很多需要考虑的因素，例如方便系统集成（考虑上游供应商使用最多的是哪个？）、实现最佳的性能和健壮性、采用何种认证途径、平台的安全性等。同时，即使当前选定了解决方案，也需要考虑技术可能发生变化的情况。实际上，无论自动驾驶汽车的开发者选择哪个解决方案，适应这个不断发展的行业中未来可能出现的任何新需求都是至关重要的问题。
方案4
使用在重要系统中已经得到成熟应用的标准化基础技术。上面提到的几种汽车平台都使用Data Distribution Service™（DDS）标准作为其核心基础。在航空航天、国防和医疗等各领域的关键任务项目中，DDS已经得到了数十年的广泛应用。该标准连接解决方案提供：
- 实时性能
- 数据的细粒度控制，包括实时的发布端过滤
- 服务质量（QoS），包括可靠性，持久性，截止期限和存活性等
- 安全性，多功能性，以及采用标准的有线协议（RTPS）来实现不同厂商之间的互操作性
DDS旨在使不同种类的上层技术更方便的集成。因此，对汽车制造企业来说，最合适的选择也许是通过DDS来集成上述一种或多种技术平台，轻松使用不同的技术平台来合理满足系统中不同的关键需求，而不必“重新设计轮子”。
分层数据总线架构
自动驾驶汽车并非一个孤立的系统。实际上，它是一个结合了不同的硬件和软件解决方案、业务逻辑、市场、供应商、业务模型等要素的体系。它需要一种独特的体系结构，既能够在边缘侧实现相当的实时性能，又能够集成不同的功能域，还能够实现各种组件之间的互操作性（即便这些组件来自于不同公司，甚至是竞争对手）。它必须是一个安全的解决方案，不仅可以防御恶意攻击，还可以保护业务逻辑。此外，它还必须能够接纳系统中大量的参与者节点，即需要良好的可伸缩性。最后，此解决方案需要（至少部分）可认证，目前业内许多子系统都需要经过ISO 26262等标准认证。
图1：汽车分层数据总线架构
图1所示的是一种分层的数据总线架构，该体系结构能够满足前文所述的需求，甚至提供更多特性。
首先，该架构允许创建互相隔离的不同功能域。每个功能域都可以包含DDS数据总线，且数据只在本功能域内进行交换。经过配置，数据只会传递给需要该数据的组件，从而减少了不必要的数据传输环节带来的资源浪费。同时，由于提供了20多种可配置的QoS策略，域内的数据通信具有高度的灵活性。这些策略能够适用于不同的应用场景，例如高吞吐量的大包数据、低延迟的数据、可靠或尽力而为、容错等等。这使我们能够获得所需的边缘性能。
DDS是一种标准，它提供了一种定义标准数据模型的简单方法，从而使数据模型能够被不同的厂商共享。同时，它也允许用户通过可扩展类型为特定的车辆定义必要的特殊细节。而且，由于DDS已被汽车标准技术所采用，因此汽车制造商可以利用AUTOSAR或ROS所需的任何部件，而只需进行最小的改动即可。此外，不同的功能域之间需要共享数据时，能够通过基于DDS的软件网关进行数据中继，这一过程能够基于数据内容自动完成。通过软件网关，我们可以对数据进行转换和适配，使其能够被不同的功能域解析和认知。例如，当数据由车内系统传输到车外时，我们可以添加唯一的标识符（例如，车牌号），或将速度数据转换为需要的其他单位。这实现了跨功能域的集成和互操作性。
图2：在自动驾驶汽车中，仅仅保护系统、主机或网络是不够的。DDS标准实现了数据流的安全性，能够在保护数据本身的同时实现高性能和可伸缩性。
DDS标准定义了细粒度的安全性策略，包括身份认证，访问控制、数据加密、数据标签、以及对异常交互的日志记录。上述策略独立于网络传输层的安全选项，完全由DDS层独立实现，因此开发人员能够根据需求灵活的在不同功能域中使用不同的安全策略。某些场景下，比如在高性能的车内通信中，开发人员没有必要浪费时间和资源来加密所有数据，只需要对诊断端口进行控制（例如，当连接一个已知的应用程序时，可以确保它只有权读取一些预先约定的信息，而无法恶意注入数据）。但再其他场景下，比如当与远程操作单元通过互联网交换某些数据时，使用安全的传输并加密所有内容就显得至关重要。这种架构能够防止其他供应商或外部应用程序接收或发送他们不应该接收或发送的数据，有效地保护系统免受攻击。
最后，这种架构能够将系统中需要不同认证级别的子系统进行隔离。一套车载系统内部往往会出现不同情况的部件，有些部件需具备最高的安全性等级（例如车辆控制部件需满足ASIL-D），而另一些部件则不需要任何安全认证（例如远程遥控）。使用上述架构，所有部件都能够使用同一套连接解决方案和设计模式，只是根据不同的安全性需求来进行功能部署。同时，依靠端到端的QoS设置（例如截止时间，存活性或可靠性），不同认证级别的系统之间也能够安全地交换数据。
许多世界顶级汽车公司之所以选择这种基于标准的实现途径，是因为它们不想被单一的技术方案所绑架。集成不同的技术和标准、提供安全和认证、可扩展到成千上万个数据点、具有很高的实时性、并能够适应将来的未知需求，选用这样一种经得起未来考验的技术非常重要。这才是未来的汽车。
相关链接
译文连载：DDS (Data Distribution Service) 数据分发服务-规范中文翻译_001
DDS科普：一文读懂DDS（数据分发服务）
BlueDCS：BLUE DCS分布式数据连接解决方案
