无人驾驶系统实现了无人驾驶所需要的各种算法，包括定位、环境感知、路径规划和控制等，无人驾驶系统是无人驾驶软件的核心部分。最后云平台提供了无人驾驶所需要的各种基础服务，共同构成了整个无人驾驶软件。无人驾驶整体软件框图如图3.1所示。
▲图3.1无人驾驶整体软件框架
从整体上看，自动驾驶包括存储、计算和基础服务3个基本需求。
实时性要求系统能够及时响应控制指令，工业设备、汽车电子、航空航天等领域都要求采用实时操作系统，因为在这些领域操作系统如果不能及时响应控制指令，会产生很严重的后果。试想一下在驾驶过程中发出了紧急刹车指令，而操作系统没有及时响应，会导致严重的交通事故。
那么什么是实时操作系统呢？
那么如何保证系统任务的实时调度呢？接下来看Linux采取的调度策略。
操作系统最基本的功能就是管理进程，Linux的进程调度采用的是CFS(CompletelyFairScheduler)算法，我们先看下没有调度和有调度的情况下的差异。
如图3.2所示单个CPU核心的情况下，左边是没有进程调度的情况，任务1在执行完成之后，会读取IO（内存、硬盘等）数据，这时候CPU会进入等待状态，CPU在等待的过程中没有做任何事情。而右边采用了调度策略，在CPU等待的过程中，任务1主动让出CPU，下一个任务就可以在当前任务等待IO的过程中执行。综上所述任务的调度合理的利用了CPU资源，使得CPU的利用率更高，从而使任务执行的更快。
▲图3.2进程调度示意图
Linux内核分为抢占式内核和非抢占式内核。非抢占式内核禁止CPU被抢占，即在一个任务执行完成之前，除非它主动让出CPU，否则CPU会一直被这个任务占据，不能够被更高优先级的任务抢占。而抢占式内核则支持在一个任务执行的过程中，如果有更高优先级的任务请求，那么内核会暂停现在执行的任务，转而执行优先级更高的任务，显然抢占式内核的实时性更好。
内核把进程做了区分，分为交互型和脚本型。如果是交互型的进程，对实时性的要求比较高，但在大部分情况下又不会一直运行。典型的情况是，键盘大部分情况下可能没有输入，但是一旦用户输入了，又要求能够立刻响应，否则用户会觉得输入很卡顿。脚本型的进程一直在后台运行，对实时性的要求没那么高，所以不需要立刻响应。Linux通过抢占式的方式，对任务的优先级进行排序，交互型进程的优先级要比脚本型进程的优先级更高。从而在交互型进程到来之时能够抢占CPU，优先运行。还有一类进程是实时进程，这类进程的优先级最高，实时进程必须要保证立刻执行，因此会有限抢占其它进程。
在多核场景下，由于每个核心的进程调度队列都是独立的，会导致一个问题：如果任务都集中在某一个CPU核心，而其它CPU核心的队列都是空闲状态，会导致CPU的整体性能下降。在这种情况下，Linux会把任务迁移到空闲的CPU核心，使得CPU核心之间的负载均衡。Linux进程迁移会带来开销，有些时候我们会绑定任务到某一个CPU核心，以减少进程迁移的开销。
参考Linux的进程调度，我们也思考下如何进行无人驾驶进程调度。
假设无人驾驶系统有以下几个进程：定位、感知、规划、控制、传感器、日志和地图，而CPU只有2个核心，那么应该如何规划这些任务的优先级呢？
首先我们假设定位、感知、规划、控制和传感器读取的优先级比日志和地图更高。这也很容易理解，打不打印日志和地图读取的慢对系统的影响不大，而定位、感知、规划，控制和传感器模块如果执行的慢，则会导致系统故障。
除此之外，无人驾驶车还需要考虑极端情况下，系统的进程会奔溃或者一直占用CPU的情况。
根据上述的思路，可以得到无人驾驶的进程调度策略，如图3.3所示。
▲图3.3进程调度策略
把控制模块的优先级设置到最高，规划模块其次，感知和定位模块的优先级设置相对较低。因为控制和规划模块必须马上处理，感知和定位模块如果当前帧处理不过来，大不了就丢弃，接着处理下一帧。当然这些进程都需要设置为实时进程。而地图、日志等模块的优先级设置为最低，在其它高优先级的进程到来之时会被抢占。
除了能够实时响应系统指令，操作系统的性能也至关重要，下面我们看下如何提高操作系统的性能。
Linux对实时进程的调度有2种方式。
cgroups名称源自控制组群（controlgroups），是Linux内核的一个功能，用来限制、控制与分离一个进程组群的资源（CPU、内存、磁盘输入输出等)。
cgroups的设计目标是为不同的应用提供统一的接口，从控制单一进程（像nice）到操作系统层虚拟化（像OpenVZ，Linux-VServer，LXC）。cgroups提供以下4个功能。
利用cgroups技术，我们可以设置一组进程的优先级，并且根据重要程度和任务类型分配不同的资源。例如给重要的进程组分配更多的CPU和内存，限制其它进程组的CPU和内存防止其影响系统性能。
CPU亲和性又叫Processoraffinity或CPUpinning。现代CPU都有多个核心，例如Apollo推荐的计算单元配置是4核8进程，多核心CPU的好处是可以同时执行多个任务。假设有以下场景，1个核心上的任务很多，而其它的核心都是空闲状态，那么就会出现1个CPU核心占用率100%，而其它的核心都在等待的情况。
操作系统采用了一种技术来解决这个问题，即CPU负载均衡。当1个CPU核心上的任务很多，而其它CPU核心是空闲状态的时候，操作系统会把这个核上的任务迁移到其它核心，系统整个CPU核心的利用率就上来了。
对整个系统来说，CPU负载均衡是一个好技术，但是对单个进程来说，就不是那么好了。进程迁移会导致额外的开销，比如当前的CACHE需要重新刷新。把重要的任务绑定到单独的核心上，可以保证这个任务的高效执行而不被打断。
Linux操作系统中通过"sched_setaffinity"来设置进程的CPU亲和性，通过"sched_getaffinity"来获取进程的CPU亲和性。
#define_GNU_SOURCE/*Seefeature_test_macros(7)*/#include
smp_affinity的默认值为f，即可为系统中任意CPU提供IRQ。将这个值设定为1，则表示只有CPU0会处理这个中断。
#echo1>/proc/irq/32/smp_affinity#cat/proc/irq/32/smp_affinity13.3运行时框架
无人驾驶车借鉴了很多机器人领域的技术，可以把无人驾驶车看做一个轮式机器人。Apollo3.5之前采用的是ROS作为底层框架，Apollo3.5之后用Cyber替换了这一框架。如果要重新设计ROS框架，我们需要支持哪些特性呢
通过分析ROS系统的功能，可以得到Cyber需要实现哪些功能。
现代机器人系统往往需要多个计算机共同执行任务，一个机器人搭载多台计算机，每台计算机分别负责机器人的一部分功能。即使只有一台计算机，我们仍然需要将程序划分为独立运行且相互协作的子模块来完成复杂的任务，这也是比较常见的做法。当多个机器人需要协同完成一个任务时，就需要互相通信，ROS为解决上述问题提供了相对简单、完备的消息通信机制。
随着机器人研究的快速推进，诞生了一批应对导航、路径规划、建图等通用任务的算法。如何将现有算法快速移植到不同系统一直是一个挑战，ROS通过以下两种方法解决这个问题。
采用上述方案的一个最大优势是实现代码的“无缝连接”，因为实体机器人、仿真器和回放的包可以提供类似的接口，上层软件不需要修改就可以与它们进行交互，实际上甚至不需要知道操作的是不是实体机器人。
参考上述实现，我们可以把需求细分为以下几个方面，如图3.4所示。
▲图3.4Cyber需求设计
实际上Cyber主要用到了ROS消息通信的功能，同时也用到了录制bag包等一些工具。
Cyber提供的功能概括起来包括4个方面，如图3.5所示。
▲图3.5Cyber功能模块
综上所述，Cyber是一个分布式消息收发和任务调度框架，同时还对外提供一系列的工具和接口来辅助开发和定位问题。Cyber对比ROS来说有很多优势，唯一的不足是Cyber没有ROS丰富的开源算法库支持。
按照上述需求，我们先实现一个分布式的系统，并且系统的各个节点之间可以互相传递消息。
▲图3.6分布式系统
图3.6所示的系统是一个分布式系统，每个节点作为一个Node，系统每个节点之间可以相互通信，一个节点下线，不会导致到整个系统瘫痪，并且该系统可以灵活的增加和删除节点。
是否还有其它的设计方式？
▲图3.7分布式系统（有主节点）
图3.7所示的系统采用了集中式的消息管理，2个节点之间的通讯必须经过主节点来完成。上述系统是一个分布式系统，每个节点作为一个Node，每个节点通过主节点通信，主节点下线会导致系统奔溃。上述系统还可以灵活的增加和删除节点。此外，上述系统存在单点问题，如果主节点下线，那么所有节点间的通信都会失败，问题的补救措施是再增加一个主节点，作为备份主节点，当一个主节点下线时，启用另一个主节点，保证系统还能够正常工作。
上述2种分布式系统的主要区别是通信方式不同。虽然集中式的消息管理方式会存在单点问题，但是集中式的消息管理方式也并不是没有好处。如图3.8所示集中式的消息处理天然支持节点管理功能，而点对点的消息处理则不支持。例如当一个节点10s都没有发送消息，那么集中式的消息管理可以监控并且发现这个节点是否出故障了。集中式的消息管理可以知道哪些节点在线并找到这些节点，这在多机网络通信的时候很管用，节点只需要注册到管理节点，然后由管理节点告诉其它节点去哪里读取消息。
▲图3.8集中式分布式系统
上述实现了一个多节点的分布式系统，要系统能够正常工作，Cyber运行时框架还需要实现以下功能，如图3.9所示。
▲图3.9Cyber系统设计
（1）多节点
（2）通信方式
▲图3.10消息发送方式
（3）资源调度
（4）软件复用
（5）快速测试
通过上述功能设计，Cyber构成了无人驾驶系统运行时框架。通过Cyber运行时框架，无人驾驶系统可以灵活的增加和删除节点，各个节点可以订阅和发布消息，可以通过协程实现任务调度，最后还提供了一些开发调试工具。
前面介绍了运行时框架，在运行时框架之上的就是无人驾驶中最重要的算法实现。算法实现有2种不同的架构，一种是模块化的软件架构，这是目前无人驾驶系统的主流方案，世界上最大的2个无人驾驶开源社区Apollo和Autoware都是采用这种架构。另一种是端到端的软件架构，和模块化的思路不同，端到端的自动驾驶直接采用传感器（摄像头等）的数据作为输入，通过深度学习模型，直接输出控制信号（油门、刹车、方向转角）控制汽车的行驶。端到端的自动驾驶结构非常简单，但性能高效。由于深度学习模型不能安全硬编码，并且具有不可解释性，目前端到端的自动驾驶更多的只是作为研究手段。
根据无人车是否联网，可以将无人驾驶车分为单车智能和网联智能，单车智能强调车本身的智能，即使在没有网络的情况下，也具备完全自动驾驶能力。而网联车则强调车和车、车和环境的交互，通过整个车联网来实现更高级的智能，车本身可以具备自动驾驶能力，也可以只具备部分自动驾驶能力，通过网络获取更高级的智能。从目前的发展趋势来看，无人驾驶车要更快的落地，单车智能和网联智能二者需要互相融合，共同发展。
▲图3.11无人驾驶软件架构
端到端的自动驾驶，在功能实现上直接把传感器的数据当做输入，经过深度学习模型，直接输出汽车的控制信号（油门，刹车、方向转角），如图3.12所示。相比基于模块的设计，端到端的结构更加简单，同时不依赖高精度地图。因为高精度地图的构建和更新成本很高，对于自动驾驶大规模部署是很大的挑战，所以不需要高精度地图是端到端架构很大的一个优势。
▲图3.12端到端结构框图
尽管端到端的自动驾驶方法和人类的驾驶方式很相似，结构简单高效，并不依赖高精度地图，但用于生产实践还需要解决以下4个问题。
由于端到端自动驾驶的局限性，目前主要还在实验阶段。相信未来随着人工智能的发展，神经进化和深度强化学习等方法将推动端到端自动驾驶的发展。
模块化的思想是将无人驾驶这个复杂问题划分为几个相对容易解决的子问题，这些子问题可以在机器人技术、计算机视觉和汽车动力学方面找到解决问题的思路，通过之前积累的经验来快速的解决问题。此外模块化的设计更加方便定界问题，修改一个模块的问题，不会影响到其它模块，这也是现代软件大量采用模块化设计的原因。
根据无人驾驶需要处理的任务类型，可以把无人驾驶分为：高精度地图、定位、感知、规划、控制、人机交互等6个模块。
（1）高精度地图比传统的地图包含的信息更多，传统的地图只有道路信息，而高精度地图除了包含道路信息之外，还包含车道信息、交通规则信息、红绿灯的位置信息等。同时高精度地图的精度需要达到厘米级，确保无人驾驶车通过高精度地图能够安全的行驶。
（2）定位模块主要解决无人车当前在哪里的问题，定位模块会实时更新无人车在地图上的精确位置，并提供给规划和控制模块使用。
（3）感知模块负责获取无人车周围的障碍物信息例如：汽车、行人、自行车等。同时还负责判断红绿灯状态、识别车道线、跟踪和预测障碍物的运动轨迹等，感知是无人驾驶中最难解决的问题之一。
（5）控制模块根据规划模块的输出，在满足汽车运动学和动力学模型的前提下，控制汽车按照规划好的线路行驶。
（6）人机交互界面实现人和车的交互，比如让乘客设置线路的起点和终点，同时提供界面展示无人驾驶车当前的状态。
▲图3.13模块化结构框图
模块化设计的优点在于算法都是可控的，可以硬编码一些规则在系统中，确保算法出错的时候，无人车依然安全。模块化的设计方案是目前无人驾驶的主流方案，后面几章我们会详细介绍无人驾驶各个模块的功能实现。
模块化的设计同时也存在一些问题。模块化的设计结构过于复杂，一个模块的错误会传导到其它模块，例如定位模块输出了错误的位置，会导致规划模块输出错误的行驶轨迹。
无人驾驶根据是否需要网络，可以分为网联智能和单车智能。网联智能的好处在于通过网络可以和其它车以及环境进行交互。目前无人驾驶车主要通过V2X作为对外通信的标准。网联智能有以下3种应用场景。
车辆编队有2种模式，一种是前车为人类驾驶员，通过记录人类驾驶员的驾驶行为，控制后面的车辆编队行驶；另一种是前车和后车都是自动驾驶车，区别是前车的自动驾驶能力更强，后车只具备部分自动驾驶能力，一部分的感知和控制任务通过前车完成，可以节省无人驾驶的落地成本。无人驾驶卡车编队如图3.14所示。
▲图3.14无人驾驶卡车编队
在无人驾驶车出现紧急或者无法处理的情况时，通过远程控制的方式可以减少现场维护的成本。远程控制的难点在于需要360°还原现场的视频画面，对传输的带宽和延时都有要求，5G网络的带宽和延时可能会使远程驾驶变得可能。
车联网是指车和车，车和环境之间通信。车联网是智慧交通的基础，通过整个汽车的联网，可以进行动态交通调度，合理规划交通线路，进一步提高城市的交通效率。
车联网对无人驾驶来说是很好的补充，并且5G网络的高带宽，低延迟特性，将来一定会在无人驾驶中有更多用武之地。
目前无人驾驶的发展还主要集中在单车智能之上，全部依靠车辆自身的传感器和算法实现自动驾驶，因为不需要依赖网络，所以在没有网络的地方同样能够实现自动驾驶。
单车智能的很多问题都能够被网联智能很好的解决，目前的发展趋势是单车智能和网联智能二者相互结合，共同发展，一起加快无人驾驶的进程。
一辆无人驾驶车配置了多种传感器包括摄像头、激光雷达、毫米波雷达、GPS、IMU等。每天使用到的数据量高达4000GB，这些数据需要收集并存储，用于高精度地图制作和模型训练。大数据存储涉及到2方面的问题：一是数据传输，二是数据存储。
数据传输需要对不同的数据类型进行分别对待。需要实时处理的数据，可以通过网络实时传回到数据中心。实时传输数据对网络的高带宽提出了要求，5G网络支持的上行速率约为50Mbps，也就是说每分钟可以上传375MB数据，还远远低于无人驾驶车的数据上传需求。这就要求我们对无人驾驶车产生的数据做分级，把高优先级的数据优先发送，低优先级的数据先保存在本地，等网络空闲之后再上传。
为了保证数据传输的经济性，需要先在本地对数据做预处理，只缓存最近2分钟的数据，对于不需要保存的数据，处理完之后直接丢弃掉，需要保存的数据压缩之后再上传。同时大部分不需要实时传输的数据可以在回到车库之后，通过WIFI进行数据传输，降低5G网络数据传输的成本。
数据存储首先需要的是一个分布式的文件系统，大数据时代已经被广泛证明了分布式文件系统的好处，最主要的好处是容量可以水平扩展，而且可靠性高。自动驾驶每天产生的大量数据都可以通过分布式文件系统保存下来。
接下来是数据库的选择，我们先分析下自动驾驶大数据应用场景和传统互联网的区别。互联网的数据生产方式是几亿用户，每人每天产生几条数据，合起来几个T的数据，而自动驾驶是一辆车每天产生几T数据，数据生产的方式差别很大。
综上所述，不同的数据需要选择不同类型的存储和数据库。自动驾驶的一些大数据场景可能根本不需要数据库，只需要文件系统就可以了，如果需要管理结构化的数据，可以用数据库存储文件路径，而把文件本身放到文件系统中。例如存储图片文件，可以只保存路径到HBase数据库，把真实的图片文件压缩之后放在对象存储中。当需要查找图片时，先通过索引找到图片对应的路径，然后再从对象存储中解压出图片。导航路线、车和用户信息等需要多用户并发访问的数据可以采用HBase保存。
深度学习模型训练、高精度地图生成以及自动驾驶仿真等都需要进行数据处理。自动驾驶的数据处理流程包括：收集、清洗、标注、训练和部署。
用于自动驾驶模型训练的数据首先需要人工标注，然后再进行模型训练，最后才能得到能够识别车辆和行人的深度学习模型。数据的自动化标注是很大的挑战，通过工程的方法尽量减少人工标注，可以大幅度提高标注效率。实现自动标注通常有2种方法：一是通过机器自动标注，然后人工修正部分数据；二是通过仿真模拟生成大量标注好的数据。
数据处理的另一个挑战是大规模并行处理数据，由于数据量巨大，如何快速的处理数据是瓶颈。有很多优秀的分布式计算框架，其中ApacheSpark可以构建大规模集群并发执行多个任务，在大规模数据处理中有非常好的实践。
总之能够快速高效的处理数据，是自动驾驶数据处理的核心竞争力。
云端应该实时提供自动驾驶所需要的地图服务。地图包括道路信息和动态信息，道路信息不用再过多介绍，就是传统的道路信息，动态信息是地图上出现堵车或交通管制等需要实时动态更新的信息。
高精度地图的道路信息比传统地图的要求更加精细，不仅仅包括道路信息，还包括车道信息、红绿灯信息、交通标志信息等。同时高精度地图的精度也比传统地图要求更高，需要达到厘米级。
除了地图本身，一些动态信息可以通过地图服务的方式下发给无人车，在高精度地图中，这部分信息被称为动态图层。例如某条路突然发生交通事故，这个信息就会下发到动态图层，无人车接收到信息之后选择避开拥堵路段。动态图层包括：交通管制、交通拥堵状态、交通规则等，还包括周围的银行、医院、便利店等生活信息，为无人驾驶提供更多更有价值的服务。
高精度地图的维护是目前面临的最大问题，因为涉及到整个地图的采集、加工和标注，实时维护大体量的高精度地图目前来说成本高昂，一些高精度地图服务提供商提出采用众包的方式更新高精度地图。
自动驾驶仿真的目的是为了更早的发现问题，业界预测要确保安全，自动驾驶的安全性测试需要行驶至少2.5亿英里。如果全部采用真实环境测试，需要1000辆无人驾驶测试车每天测试100英里，不间断测试6.8年，短期内不可能实现。如果采用自动驾驶仿真，通过模拟真实场景的数据，让无人车大规模部署在虚拟环境中测试，然后再去真实场景路测，可以极大提高发现问题的效率。自动驾驶仿真测试流程如图3.15所示。目前Waymo宣称已经在现实世界中路测了1000万英里，在模拟世界中测试了100多亿英里。
▲图3.15无人驾驶测试流程
除了自动驾驶功能测试，仿真还可以通过生成数据来帮助模型训练。数据的生成方式有2种，一种方式是生成标注好的数据，通过在仿真环境中模拟真实的车辆、行人、建筑物等，这些信息在仿真环境中都是已知的，可以直接生成标注好的数据用来进行模型训练。另一种方式是利用强化学习在仿真环境中模拟开车，进行端到端的自动驾驶模型训练，英伟达发布的端到端自动驾驶训练就是采用的此方法。
自动驾驶需要深度学习模型来做感知任务。深度学习模型需要通过模型训练得到，模型训练包括数据采集、标注、模型训练、调参、测试、部署等6个步骤。主流的云平台目前都支持上述的模型训练部署过程，在云上的好处在于，计算资源动态调配，扩展和部署起来相当方便。同时云平台支持各种主流的机器学习框架，不需要自己一步一步从头搭建环境。
要运营数量庞大的无人驾驶车队，车辆的配置管理必不可少。即使无人驾驶车的硬件配置基本一样，每辆无人驾驶车的参数还需要微调，同时根据运营的区域不同，获取的地图和交通规则也不同。
配置服务通过以下方式对无人驾驶车进行配置管理：给每辆无人车设置一个唯一的车辆ID，在无人车启动的时候，先检查配置是否正确，然后检查配置是否需要更新，如果需要更新，则根据唯一的车辆ID去数据中心下载这辆车的配置信息。以下是无人车需要下载的配置参数。
除了上述配置，无人驾驶车还用到了数目众多的传感器，虽然出厂的时候已经对传感器参数做了校准，但在车驾驶之前，传感器参数都要进行轻微的校准，以达到最佳效果。以特斯拉为例，当model3车主开车行驶大概20-25英里之后才会完成摄像头参数的校准。
在线升级服务(OTA，OverTheAir)，通过网络更新汽车的软件，OTA在汽车软件迭代快速的情况下通过软件升级汽车系统。在线升级服务不需要召回汽车，通过软件升级的方式来增加新功能、修复bug，既提升了用户体验，又节省了成本。比较典型的场景是特斯拉一夜之间升级了model3，让车具备了辅助驾驶能力。
（1）无人车监控
无人车的监控包括2个层面：应用层面和系统层面。
（2）无人车调度
自动驾驶打车服务和货运服务都需要车辆调度算法。自动驾驶打车服务要及时找到乘客附近的车辆，好的调度算法可以避免用户等待。在无人驾驶货运场景，特别是在一些港口，调度系统需要和专业的港口调度软件相结合，实现智慧物流，提高港口货运效率。
调度平台还可以结合智慧城市，通过城市大脑动态的调度无人车，从而改善交通拥堵，实现智慧出行。
无人驾驶最主要的2个应用服务是无人驾驶出租车和无人驾驶物流，无人驾驶打车服务和现在的滴滴打车类似，只是不需要司机。而无人驾驶物流服务，包括长途货运，港口运输，以及快递小车等。
除了上述服务之外，随着无人车高度智能化，会出现更多的应用软件，提供资讯、天气、支付等服务。在解放了人类驾驶员之后，汽车可能会变为另一个娱乐和办公场所，用户可以选择音乐、游戏、以及视频会议等服务。
可以预见未来无人驾驶车将会给人们的生活带来非常巨大的改变。
无人驾驶车的软件涉及到方方面面，不仅包括操作系统，中间件，云服务的构建，还包括各种软件算法，调试诊断工具，可视化工具，人机交互界面，同时还包括上层应用软件，以及为这些软件提供升级的OTA服务等。正如汽车是工业之母，无人驾驶车软件未来也将会成为继PC、手机之后最大的软件终端之一。