无人驾驶软件分为车辆端和云端2个部分，其中车辆端运行操作系统和无人驾驶系统，云端提供无人驾驶所需要的各种服务。
无人驾驶系统实现了无人驾驶所需要的各种算法，包括定位、环境感知、路径规划和控制等，无人驾驶系统是无人驾驶软件的核心部分。最后云平台提供了无人驾驶所需要的各种基础服务，共同构成了整个无人驾驶软件。无人驾驶整体软件框图如图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的情况。
找不到最优解，死循环。大部分情况下程序没有响应是因为找不到最优解，或者死循环，这种情况可以通过代码保证。
堆栈溢出、内存泄露、空指针。这种情况属于程序编码错误，也可以通过代码保证。
硬件错误。极小概率的情况下，CPU的寄存器会出错，嵌入式的CPU会有冗余校正，而家用和服务器级别的CPU没有这种设计，这种情况下只能重启进程，或者重启硬件。
根据上述的思路，可以得到无人驾驶的进程调度策略，如图3.3所示。
▲图3.3进程调度策略
把控制模块的优先级设置到最高，规划模块其次，感知和定位模块的优先级设置相对较低。因为控制和规划模块必须马上处理，感知和定位模块如果当前帧处理不过来，大不了就丢弃，接着处理下一帧。当然这些进程都需要设置为实时进程。而地图、日志等模块的优先级设置为最低，在其它高优先级的进程到来之时会被抢占。
除了能够实时响应系统指令，操作系统的性能也至关重要，下面我们看下如何提高操作系统的性能。
Linux对实时进程的调度有2种方式。
SCHED_FIFO。先到的进程优先执行，后到的进程需要等待之前的进程执行完成之后才开始执行。
cgroups名称源自控制组群（controlgroups），是Linux内核的一个功能，用来限制、控制与分离一个进程组群的资源（CPU、内存、磁盘输入输出等)。
cgroups的设计目标是为不同的应用提供统一的接口，从控制单一进程（像nice）到操作系统层虚拟化（像OpenVZ，Linux-VServer，LXC）。cgroups提供以下4个功能。
资源限制：组可以被设置不超过设定的内存大小，也包括虚拟内存。
优先级：一些组可能会得到大量的CPU或磁盘IO吞吐量。
结算：用来衡量系统确实把多少资源用到适合的目的上。
控制：冻结组或检查点和重启动。
利用cgroups技术，我们可以设置一组进程的优先级，并且根据重要程度和任务类型分配不同的资源。例如给重要的进程组分配更多的CPU和内存，限制其它进程组的CPU和内存防止其影响系统性能。
CPU亲和性又叫Processoraffinity或CPUpinning。现代CPU都有多个核心，例如Apollo推荐的计算单元配置是4核8进程，多核心CPU的好处是可以同时执行多个任务。假设有以下场景，1个核心上的任务很多，而其它的核心都是空闲状态，那么就会出现1个CPU核心占用率100%，而其它的核心都在等待的情况。
操作系统采用了一种技术来解决这个问题，即CPU负载均衡。当1个CPU核心上的任务很多，而其它CPU核心是空闲状态的时候，操作系统会把这个核上的任务迁移到其它核心，系统整个CPU核心的利用率就上来了。
#define_GNU_SOURCE/*Seefeature_test_macros(7)*/
#include
intsched_setaffinity(pid_tpid,size_tcpusetsize,
cpu_set_t*mask);
intsched_getaffinity(pid_tpid,size_tcpusetsize,
smp_affinity的默认值为f，即可为系统中任意CPU提供IRQ。将这个值设定为1，则表示只有CPU0会处理这个中断。
#echo1>/proc/irq/32/smp_affinity
#cat/proc/irq/32/smp_affinity
1
3.3运行时框架
无人驾驶车借鉴了很多机器人领域的技术，可以把无人驾驶车看做一个轮式机器人。Apollo3.5之前采用的是ROS作为底层框架，Apollo3.5之后用Cyber替换了这一框架。如果要重新设计ROS框架，我们需要支持哪些特性呢
通过分析ROS系统的功能，可以得到Cyber需要实现哪些功能。
随着机器人研究的快速推进，诞生了一批应对导航、路径规划、建图等通用任务的算法。如何将现有算法快速移植到不同系统一直是一个挑战，ROS通过以下两种方法解决这个问题。
ROS标准包（StandardPackages）提供稳定、可调式的各类机器人算法实现。
ROS系统框架将底层硬件控制模块和顶层数据处理与决策模块分离，从而可以使用模拟器替代底层硬件模块，独立测试顶层部分，提高测试效率。
采用上述方案的一个最大优势是实现代码的“无缝连接”，因为实体机器人、仿真器和回放的包可以提供类似的接口，上层软件不需要修改就可以与它们进行交互，实际上甚至不需要知道操作的是不是实体机器人。
参考上述实现，我们可以把需求细分为以下几个方面，如图3.4所示。
▲图3.4Cyber需求设计
实际上Cyber主要用到了ROS消息通信的功能，同时也用到了录制bag包等一些工具。
Cyber提供的功能概括起来包括4个方面，如图3.5所示。
消息队列。用于接收和发送各个节点的消息，负责消息的订阅、发布以及消息缓存等。
实时调度。负责任务调度，保证算法模块能够实时处理消息。
用户接口。提供灵活的用户API接口。
工具。提供一系列的工具，例如bag包播放、点云可视化、消息监控等。
▲图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）资源调度
进程有优先级。能够设置进程的优先级，优先级高的进程优先执行，优先级低的进程能够被优先级高的进程抢占。
支持并发。支持多个任务并行执行。
能够限制系统的资源占用。能够限制进程对系统资源（CPU、内存）的占用。
协程。协程是轻量级的进程，协程工作在用户态，切换的开销比进程小，不需要频繁的系统调度，协程消耗的系统资源也比进程少。协程和进程不同，除非自己主动退出，否则会一直占用CPU。Cyber系统在进程的基础上，启用了协程，用于处理大量的消息队列。无人驾驶系统每秒钟会发送大量的消息，如果频繁的进行IO切换，带来的系统调用开销将会非常明显。
（4）软件复用
包管理。支持加载其它第三方的算法库。
工具类。有一些基础功能的公共组件。
统一的消息格式。具有统一的消息格式，避免因为消息格式不一样带来的重复开发。
（5）快速测试
人机交互。具备可视化的人机交互界面。
日志。能够记录系统日志信息。
调试功能。实时监控无人驾驶系统消息通道、消息频率、消息格式等。提供消息持久化工具，能根据录制好的包，进行场景回放。
通过上述功能设计，Cyber构成了无人驾驶系统运行时框架。通过Cyber运行时框架，无人驾驶系统可以灵活的增加和删除节点，各个节点可以订阅和发布消息，可以通过协程实现任务调度，最后还提供了一些开发调试工具。
前面介绍了运行时框架，在运行时框架之上的就是无人驾驶中最重要的算法实现。算法实现有2种不同的架构，一种是模块化的软件架构，这是目前无人驾驶系统的主流方案，世界上最大的2个无人驾驶开源社区Apollo和Autoware都是采用这种架构。另一种是端到端的软件架构，和模块化的思路不同，端到端的自动驾驶直接采用传感器（摄像头等）的数据作为输入，通过深度学习模型，直接输出控制信号（油门、刹车、方向转角）控制汽车的行驶。端到端的自动驾驶结构非常简单，但性能高效。由于深度学习模型不能安全硬编码，并且具有不可解释性，目前端到端的自动驾驶更多的只是作为研究手段。
根据无人车是否联网，可以将无人驾驶车分为单车智能和网联智能，单车智能强调车本身的智能，即使在没有网络的情况下，也具备完全自动驾驶能力。而网联车则强调车和车、车和环境的交互，通过整个车联网来实现更高级的智能，车本身可以具备自动驾驶能力，也可以只具备部分自动驾驶能力，通过网络获取更高级的智能。从目前的发展趋势来看，无人驾驶车要更快的落地，单车智能和网联智能二者需要互相融合，共同发展。
▲图3.11无人驾驶软件架构
端到端的自动驾驶，在功能实现上直接把传感器的数据当做输入，经过深度学习模型，直接输出汽车的控制信号（油门，刹车、方向转角），如图3.12所示。相比基于模块的设计，端到端的结构更加简单，同时不依赖高精度地图。因为高精度地图的构建和更新成本很高，对于自动驾驶大规模部署是很大的挑战，所以不需要高精度地图是端到端架构很大的一个优势。
▲图3.12端到端结构框图
尽管端到端的自动驾驶方法和人类的驾驶方式很相似，结构简单高效，并不依赖高精度地图，但用于生产实践还需要解决以下4个问题。
端到端的自动驾驶需要对不同的车型重新训练模型，生产和制造过程中迁移和升级的成本太高，达不到软件的零边际成本。即使车辆型号一致，车辆出厂之前还需要对摄像头等传感器的参数进行微调，以达到最佳效果。
可解释性差。自动驾驶过程中的感知、决策和规划都是通过深度学习模型完成的，出现故障后，没法分析具体的原因。
只能根据目前已知的数据进行推断，对于陌生的数据适应性会变差，可能会作出错误的决策。也就是说在特殊场景下，算法可能会失控。
不能硬编码安全规则。在算法失控的时候，不能保证安全。
由于端到端自动驾驶的局限性，目前主要还在实验阶段。相信未来随着人工智能的发展，神经进化和深度强化学习等方法将推动端到端自动驾驶的发展。
根据无人驾驶需要处理的任务类型，可以把无人驾驶分为：高精度地图、定位、感知、规划、控制、人机交互等6个模块。
（1）高精度地图比传统的地图包含的信息更多，传统的地图只有道路信息，而高精度地图除了包含道路信息之外，还包含车道信息、交通规则信息、红绿灯的位置信息等。同时高精度地图的精度需要达到厘米级，确保无人驾驶车通过高精度地图能够安全的行驶。
（2）定位模块主要解决无人车当前在哪里的问题，定位模块会实时更新无人车在地图上的精确位置，并提供给规划和控制模块使用。
（3）感知模块负责获取无人车周围的障碍物信息例如：汽车、行人、自行车等。同时还负责判断红绿灯状态、识别车道线、跟踪和预测障碍物的运动轨迹等，感知是无人驾驶中最难解决的问题之一。
（5）控制模块根据规划模块的输出，在满足汽车运动学和动力学模型的前提下，控制汽车按照规划好的线路行驶。
（6）人机交互界面实现人和车的交互，比如让乘客设置线路的起点和终点，同时提供界面展示无人驾驶车当前的状态。
▲图3.13模块化结构框图
模块化设计的优点在于算法都是可控的，可以硬编码一些规则在系统中，确保算法出错的时候，无人车依然安全。模块化的设计方案是目前无人驾驶的主流方案，后面几章我们会详细介绍无人驾驶各个模块的功能实现。
模块化的设计同时也存在一些问题。模块化的设计结构过于复杂，一个模块的错误会传导到其它模块，例如定位模块输出了错误的位置，会导致规划模块输出错误的行驶轨迹。
车辆编队有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无人驾驶测试流程
自动驾驶需要深度学习模型来做感知任务。深度学习模型需要通过模型训练得到，模型训练包括数据采集、标注、模型训练、调参、测试、部署等6个步骤。主流的云平台目前都支持上述的模型训练部署过程，在云上的好处在于，计算资源动态调配，扩展和部署起来相当方便。同时云平台支持各种主流的机器学习框架，不需要自己一步一步从头搭建环境。
要运营数量庞大的无人驾驶车队，车辆的配置管理必不可少。即使无人驾驶车的硬件配置基本一样，每辆无人驾驶车的参数还需要微调，同时根据运营的区域不同，获取的地图和交通规则也不同。
配置服务通过以下方式对无人驾驶车进行配置管理：给每辆无人车设置一个唯一的车辆ID，在无人车启动的时候，先检查配置是否正确，然后检查配置是否需要更新，如果需要更新，则根据唯一的车辆ID去数据中心下载这辆车的配置信息。以下是无人车需要下载的配置参数。
车辆的唯一ID
车的型号
传感器的参数
地图
各个模块的策略等配置信息
（1）无人车监控
无人车的监控包括2个层面：应用层面和系统层面。
应用层面。为了确保安全，需要实时监控无人车的位置，如果无人车的位置丢失，或者偏离预定线路，监控系统需要及时给出警告，通知维护人员去处理。同时监控系统也需要在无人车主动触发警报之后，及时通知救援。
系统层面。在自动驾驶模式启动之前进行自检，确保汽车的各项指标都没有问题之后，才开始进入自动驾驶模式。在自动驾驶过程中，通过记录当前无人驾驶系统的日志信息，可以实时监控无人车的状态。
（2）无人车调度
无人驾驶最主要的2个应用服务是无人驾驶出租车和无人驾驶物流，无人驾驶打车服务和现在的滴滴打车类似，只是不需要司机。而无人驾驶物流服务，包括长途货运，港口运输，以及快递小车等。
除了上述服务之外，随着无人车高度智能化，会出现更多的应用软件，提供资讯、天气、支付等服务。在解放了人类驾驶员之后，汽车可能会变为另一个娱乐和办公场所，用户可以选择音乐、游戏、以及视频会议等服务。
可以预见未来无人驾驶车将会给人们的生活带来非常巨大的改变。
无人驾驶车的软件涉及到方方面面，不仅包括操作系统，中间件，云服务的构建，还包括各种软件算法，调试诊断工具，可视化工具，人机交互界面，同时还包括上层应用软件，以及为这些软件提供升级的OTA服务等。正如汽车是工业之母，无人驾驶车软件未来也将会成为继PC、手机之后最大的软件终端之一。