车载客户端子系统集成了上诉算法，来满足实时和可靠性的需求。客户端系统要应对三大主要的挑战：1）系统需要确保处理管道足够快，才能及时消化掉传感器产生的海量数据；2）如果系统的部分失效了，系统自己必须保证足够鲁棒，从而能从失效中恢复；3）系统需要在有限的供电和计算资源的情况下完成所有的运算。

　　机器人操作系统

　　机器人操作系统（ROS）是一个专门为机器人应用而设计的，被广泛使用的高性能分布式的计算框架（参见图6）。

　　每个机器人所要完成的任务（如自身定位）都由一个ROS的子节点处理。这些节点间是通过话题和服务进行相互连接的。它对于自主驾驶而言是一个合适的操作系统，但也有一些问题：

可靠性：ROS只有一个主节点而且对子节点没有监控，从而无法实现失效恢复。

性能：在发送广播消息的时候，ROS会把消息复制多份，这就导致性能的降低。

安全性：ROS没有认证和加密的机制。

　　虽然ROS 2.0版宣称要修复这些问题，但它还没有被广泛的测试过，并且很多特性也没有实现。

　　为了在自主驾驶车辆上使用ROS，我们需要先解决这几个问题。

图6 机器人操作系统（ROS）。图片由Shaoshan Liu友情提供

　　可靠性

　　现有版本的ROS的实现仅有一个主节点。因此当主节点崩溃时，整个系统就崩溃了。这一点并不能满足自主驾驶的安全性要求。为了解决这一问题，我们在ROS上实现了一个类似ZooKeeper的机制。如图7所示，这个设计包含一个主节点和一个备份主节点。当主节点失效时，备份节点就接替主节点，并确保系统能持续运行无间断。另外，ZooKeeper的机制还可以监控所有节点，并在节点失效时重启它们。从而可以确保整个系统的可靠性。

图7 ROS上使用ZooKeeper。图片由Shaoshan Liu友情提供

　　性能

　　性能问题是现有ROS实现的另外一个缺陷。ROS节点间通信很频繁，因此节点之间的通信就必须是非常高效的。首先，ROS客户端节点间的通信采用的是环回机制。每完成一次环回的管道，就会带来约20毫秒的开销。为了降低这个节点间通信的开销，我们可以使用共享内存的机制来避免消息传输必须经过TCP/IP的打包/拆包的过程。另外，ROS的节点在广播消息的时候，消息会被复制多次，极大地占用了系统带宽。改用多点传送机制就能够很好地提升系统吞吐量。

　　安全性

　　安全性问题是ROS的最大的死穴。设想两个场景：第一个，某个ROS的节点被“黑”了，随后操作系统内存被持续的占用并最终导致内存溢出，从而开始杀掉其他的ROS的节点。最终黑客成功地让整个系统崩溃。第二个场景，ROS的消息默认是不加密的。黑客可以很容易地监听节点间的通信，然后使用消息拦截机制发动攻击。

　　为了解决第一个安全问题，我们可以使用Linux容器机制（LXC）来限制每个节点可以使用的资源数量，并提供沙箱机制来防止一个节点被其他节点破坏。这样可以有效地防止资源溢出。对于第二个问题，可以通过加密消息来阻止消息被窃听。

　　硬件平台

　　为了能更好地理解为自主驾驶车辆设计硬件平台的挑战，让我们先看看某个行业领先的企业的计算平台的实现。这个计算平台包括两个计算系统，每个装备了Intel Xeon E5处理器，以及4到8个Nvidia Tesla K80 GPU加速处理器。第二个系统完成与第一个系统一模一样的任务，从而保证了可靠性。当第一个系统失效的时候，第二个系统可以立即接手工作。

　　最差的情况下，如果两套系统都工作在最大功耗，共计使用超过5000瓦的电量，同时产生非常多的热量。每套系统的价格在2万到3万美元之间，远远超出了一般消费者的承受能力。