车辆控制中的“实时性”及其影响因素
交流群 | 进“传感器群/滑板底盘群”请加微信号：xsh041388
交流群 | 进“域控制器群/操作系统群”请加微信号：ckc1087
备注信息：传感器/滑板底盘/域控制器+真实姓名、公司、岗位
本文同步发布在汽车软件开发交流公益社区，更多精彩内容欢迎点击文末“阅读原文”，进入社区，深度交流。
引言
在最近一起有公开报道的辅助驾驶相关事故中，由于AEB（自动紧急制动系统）功能被怀疑没有起作用，又有一家车企的高级辅助驾驶功能遭到质疑。其实，目前大多数车辆中AEB功能的生效车速区间在70km/h以下，美国公路安全保险协会IIHS对新车AEB的最高测试速度仅为40km/h。
AEB功能之所以跟车辆速度强相关，主要是由于车辆从检测到障碍物到采取刹车动作需要一定的时间，而车速越快，留给系统反应的时间就越少。在传感器探测能力确定的情况下，系统从评估传入的传感器数据到启动刹车必须在毫秒级（如300ms）的时间内完成，否者就可能为时已晚，失去了意义。这正是行业对于 “高实时性”要求的具体体现。
图：实时系统（参考文献9）
然而，行业内很多人对于“实时性”这一概念实际上却存在着很大的误解，在智能驾驶相关开发中也没有给予足够的重视，对于提升系统的“实时性”也缺乏系统性思路。比如：
汽车电子领域的“实时性”就是指系统跑得快么？
把MCU换成MPU，系统的实时性就提升了么？
为什么说AUTOSAR CP的实时性要优于AUTOSAR AP？
采用实时操作系统，系统是不是就满足实时性要求了？
以太网、5G为什么也强调要支持确定性通信？
什么是端到端的系统级实时性？
系统实时性的影响因素有哪些？如何优化？
希望本文能有助于大家更准确地理解车辆控制系统中的实时性，并能够对实时性问题进行系统、全面的分析，从而使得开发出的智能驾驶产品功能更可靠，性能表现更优，真正降低交通事故的概率和产生的危害。
什么是实时系统？
如果我们问一个软件开发人员，尤其是IT行业的软件工程师，“实时”是什么意思，得到的回答大概率是：“实时”就是非常快、或者几乎感觉不到延迟。对于常人而言，这么理解倒是也可以；但对于嵌入式领域，尤其是涉及人身安全的自动驾驶、整车控制等系统而言，这个回答完全没Get到“实时”二字的真谛。
其实，对于嵌入式领域而言，“实时”应理解为“及时”，英文用“in time”表达，即强调系统应在一个确定的时间内完成特定的任务，追求“确定性”和“可预期”。
假设有一个任务交给两个系统分别处理，A系统处理平均需要10ms，且每次都能确保在12ms内处理完毕，而B系统平均处理只需要5ms，但某些情况下可能要花费20ms、50ms甚至更久才能完成。由此，我们可以认为A系统的实时性更好。
可见，在本质上，实时性跟系统运行的“快慢”其实没有必然关系。
实际应用中，不同系统对于实时性的满足程度并不相同。为此，人们根据系统对规定时间内完成任务的敏感性不同，将实时系统分为“硬实时系统”和“软实时系统”。
图：不同系统对于实时性的要求程度不同（来源：网络）
硬实时系统（Hard Real-time）严格限定在规定的时间内完成任务，否则就可能导致系统功能的失效。例如对于线控转向，如果驾驶员发出转向操作后100ms内车轮没有执行转向，则可能导致碰撞事故，严重的甚至造成车毁人亡。
软实时系统（Soft Real-time）则要求没有这么严格，允许出现一定的时间偏差。软实时只能提供统计意义上的实时性，例如有的应用要求系统在95%的情况下能够确保在规定时间内完成任务即可。车辆信息娱乐域的系统大多都属于软实时系统。
总之，实时性是一个相对的概念，如同功能安全，也分不同等级，需要根据系统的功能要求，综合平衡系统升级的灵活性、成本等不同因素，设计“够用”的实时性即可。
车内的各种系统对实时性有不同的要求。以AUTOSAR标准为例，CP通常用于硬实时系统中，而AP多用于对实时性要求较低、但又比用于车机的Android实时性要求高的系统，如下图所示。
图：AUTOSAR CP系统、AP系统及信息娱乐系统对于实时性、安全性和计算能力有着不同的要求（参考文献7）
如何理解三者在实时性方面的差异呢？我们以操作系统理论中经常提及的“优先级反转”为例来简单解释下。
“优先级反转”是指一个正在访问临界区资源的低优先级任务或进程，导致其它高优先级任务或进程反而必须等待而被延迟响应的情况。在实时应用中，这是一个十分严重的问题。在基于最大吞吐量原则进行调度的常规Linux系统中，如Android系统，这个问题甚至被认为是影响系统实时性的最重要原因。而Linux的另一个版本——RT-Linux，则在常规Linux的基础上，通过对“优先级反转”等问题的优化，提升了系统的实时性。
AUTOSAR AP运行所基于的操作系统尽管与Linux一样都是符合POSIX标准的操作系统，如QNX操作系统，但可以认为是类似于经过实时性优化的RT-Linux，因而其实时性是要优于车机中应用的Android系统的。
AUTOSAR CP中所定义的OS由于是一个完全静态（任务数量、优先级都是确定的，运行过程中不会变）的操作系统，因而针对“优先级反转”问题可以进一步优化，通过“优先级天花板协议（Priority Ceiling Protocol）”的方法，从而实现比RT-Linux更高的实时性。因此，AUTOSAR CP的实时性定位要高于AUTOSAR AP的实时性定位，尤其是能够满足硬实时系统的要求。
那是不是只要系统使用了AUTOSAR CP，或者某个宣称是硬实时操作系统的OS，就算是一个硬实时系统了呢？实际情况远远没有这么简单，影响系统实时性的因素非常多。
AUTOSAR标准从R4.x版本开始，专门引入了Timing Analysis这一新方法。在这里，Timing一词，中文多习惯译为“时序”，可以认为等效于“实时性”。
什么是系统级实时性
为了说清楚这个问题，我们首先来看一个AUTOSAR标准中所举的主动转向的例子。如下图所示：
图：主动转向系统中的端到端时序要求（参考文献1）
整个系统包含传感器、两个ECU、CAN和Flexray总线以及执行器。功能大意是通过对车辆侧倾角度的持续监测，及时主动调整转向，避免车辆侧翻。功能开发人员根据车辆动态模型和主动转向功能的定义，提出了整个事件链（Event chain）的最大响应时间不能超过30ms的要求。显然，这是一个典型的硬实时要求。
这一实时性要求或时序（Timing）要求可根据事件链上所涉及的事件，分解为T1~T5五个部分，其中T1、T3、T5为通信传输用时，而T2和T4为ECU内部处理用时。
从这个例子中不难看出，系统的实时性分析需要首先明确“系统”一词所指的范围。在车辆控制中，尤其是自动驾驶，实时性应该更多指端到端的时序（End-to-End Timing），而不能只是孤立地看某个控制器或某条通信总线的实时性。因此，要想优化系统的实时性，则不仅需要从ECU内部功能入手，还需要考虑信息传递所涉及的各种通信过程。
影响系统实时性的三大层面、九个层级
总体而言，影响系统实时性的因素可以分为通信层面、调度层面和代码层面三个层面，而每个层面中又有多个层级，总计可划分成九个主要层级。
01
通信层面
通信层面的时间主要指信号在网络总线上的传输所消耗的时间。其中，报文响应时间、带宽、利用率（Payload）以及数据缓冲区大小对该层面的时间影响重大。
在这一层面上，开发过程中关注的重点往往是端到端时间（如从传感器到执行器）或者软件中一个本地事件到服务器上的另一个事件的时间差。具体而言，又可分细为三个层级：
（1）V2X层级：即车辆与外界进行数据通信时所需的时间。如V2V场景中，前车在检测到危险时向跟随在后方的车辆发出警示。显然，警示信息的传递不应太久。
典型解决方案：
优化车辆与外部世界通信实时性的一个典型实例就是5G确定性网络。手机偶尔有一两秒没信号或许不是什么大问题，但对于汽车而言，未来要想实现基于云端的车辆控制，实时性是必须解决的问题。
传统的4G网络由于IP网络“分组交换”带来的传输路径不确定，无法提供延迟、丢包和抖动的最坏情况界限，就无法提供确定的延迟，难以保证信号“及时”地传送到目的地，而5G确定性网络则有可能解决这些问题，从而提高这一层级的实时性。
图：5G确定性网络联盟（来源：网络）
2019年5月，华为在第三届未来网络大会上，提出了5G确定性网络。对于这一概念，华为联合信通院、三大运营商在2020年共同发布的《5G确定性网络产业白皮书》中做了如下定义：
5G确定性网络（5GDN：5G Deterministic Networking），是指利用5G网络资源打造可预期、可规划、可验证，有确定性能力的移动专网，提供差异化的业务体验。
（2）车内网络：车内不同ECU之间通过网络进行数据交互所需的时间。如系统通常要求刹车踏板踩下200ms之内亮起刹车灯，而刹车信号检测和刹车灯的控制往往不是在同一个ECU内完成，有时甚至要经过一个网关。这中间可能涉及同一个信号在不同总线上的多次传输。这些传输过程的实时性同样不容忽视，应尽量避免延迟、丢帧等问题。
典型解决方案：
TSN(Time-sensitiveNetworking，时间敏感网络)可以说是这一层级当前最热的话题。针对车内日益增多的以太网通信，由TSN工作组制定的相关标准的核心目标就是提升这一层级的实时性。
图：Time-sensitiveNetworking，时间敏感网络（来源：网络）
传统的以太网是一种“尽力而为”（Best effort）的传输方式。而TSN以太网是一种以时钟同步为基础实现对不同流量（时间敏感流量/非时间敏感流量，可抢占帧/不可抢占帧）的调度，兼顾帧的过滤和冗余设计，从而实现确定性通信。
顺带说一下，5G确定性网络中其实也包含对TSN技术的应用。也就是说，某些提高系统实时性的技术解决方案可能应用于多个不同层级，而不一定仅局限于某一个层级。
（3）ECU内部：在ECU内部，多个通过SPI或I2C等方式连接在一起的芯片之间或异构SoC内核之间进行数据交互所需的时间。如中央域控制器中MCU与MPU之间数据的传输，异构多核SoC内部实时核与计算核之间的通信，还有电池管理控制器中MCU和电芯采样芯片之间的通信，这些通信耗时对于系统实时性的影响也不容忽视。
典型解决方案：
TDA4中的IPC驱动包是这方面的一个好例子。TI开发的Jacinto 7 SoC在一个SoC上有多个不同的CPU，包括Cortex-R5F、Cortex-A72等。在这些CPU上运行的软件需要相互协作，也就必然需要相互通信。因此协作方式通常被称为处理器间通信或IPC（Intra Processor Communication）。每个CPU和操作系统上都提供了IPC驱动包，以支持更上层的应用程序之间相互通信。
图：TDA4 IPC消息收发过程（参考文献8）
为了提高通信效率，IPC驱动包利用了芯片中提供的硬件邮箱资源，同时还采用了基于共享内存的消息队列，从而可以有效减少通信拥堵情况的发生，为实现核间通信的确定性提供了良好的基础，有助于提升系统的实时性。
02
调度层面
调度层面也就是常说的操作系统层面，该层面对于任务的响应时间（Response Time）影响重大，而响应时间是调度理论中最重要的时间参数，它表征了从需要执行任务到任务执行完毕所经过的时间，是衡量操作系统是否为硬实时操作系统的核心因素。考虑到日益普遍的多核处理器，这一层面也可进一步细分为两个层级：
（1）SoC层级：对于多核处理器，任务在各个CPU之间的分配与调度策略会影响系统所有与时间有关的行为。例如，在访问核间共享的数据时，为确保数据一致性，不同CPU上运行的软件之间需要同步，进而产生额外时间开销，延迟响应时间。
典型解决方案：
Amdahl定律给出的启示。针对多核引入后的并行计算，计算机专家Gene Amdahl早在半个世纪前就发现，系统性能的提升潜力在很大程度上取决于这些软件中必须按顺序处理（没办法并行处理）的部分所占的比例。
因此，即使CPU数量持续增加也将不再带来任何实际计算能力的提升。即随着CPU内核的增加，处理速度的提升将逐渐接近水平线。打个通俗点儿的比喻：请两个人装修房子需要花10天完成的话，请十个人并不能保证2天内完成，而极可能是至少需要5天，且增加再多的人也没用。
图：Amdahl定律（来源：网络）
对于车辆上控制相关功能而言，通常包含很多难以并行化的因素，要么功能在逻辑上不允许，要么项目需要重用之前基于单核MCU开发的大部分软件。
有人可能说，英伟达的高端GPU不是都已集成数千个CUDA内核了么？对此，有必要澄清一点：控制类算法、复杂状态机以及不同通信总线之间传输报文的网关，它们与可以轻松分布在成百上千个图形计算核心上的渲染引擎不具有可比性，即后者可以轻松支持并行处理，而前者则很难。
但是，这也给了我们一个重要启示：要想在车辆控制中利用好多核处理器，就必须尽可能地将各种功能进行解耦，形成一系列相对独立的Function Cluster(功能簇)，以便可以同时跑在多个内核上。
（2）CPU层级：对于单核MCU或多核SoC中的单个CPU，一次只能处理一个任务，要执行另一个任务（如中断）就必须先暂停当前的任务。所以，CPU层级调度就是指执行单核调度的层级。
典型解决方案：
这里我们以支持抢占式调度的AUTOSAR OS为例。为了保证系统满足硬实时的要求，AUTOSAR标准提出了Timing Protection的概念，通过确保影响任务响应时间因素的上限或者下限来优化系统的实时性。具体而言就是：
保证任务或中断的执行不超出预设的最长执行时间；
保证共享资源被锁的时间不超出预设的最长时间；
保证中断被禁止的时间不超过预设的最长时间；
保证任务的激活间隔不低于预设的时间；
保证中断的发生间隔不低于预设的时间；
其实，这五条可以概括为两种时序保护机制：
A. 执行时间预算保护，即防止任务或中断超出允许执行的最长时间；
B. 执行频次保护，即防止任务或中断的产生频率超出允许的范围；
需要说明的是，实际开发中，准确计算最长执行执行时间非常困难，对于多核MCU，这更加不可能。有关这部分的讨论超出了本文的范围，感兴趣的读者可以查阅静态代码分析相关技术，其中德国AbsInt公司开发的aiT分析软件是这方面的代表性工具。
03
代码层面
代码层面的分析重点是代码执行所需的时间，即净运行时间（Core Execution Time），不包括因中断等原因造成的打断所增加的时间（这部分时间在调度层面进行考虑）。在代码层面进行分析活动的最有价值输出就是前面提到的任务或中断的最长执行时间（Worst Case Execution Time）这一时间参数。根据不同的颗粒度，代码层面可进一步细分为四个层级：
（1）函数层级：这里的“函数”指所有与函数（C/C++中function的概念）类似的结构，包括AUTOSAR OS任务和中断服务例程，POSIX系统中的Thread等。
以AUTOSAR OS为例，任务（Task）会调用一系列Runnable，而Runnable内含有若干子函数。因此，根据函数的不同层次，可进一步分为任务/中断层级、Runnable层级（顶层函数）、一般函数层级（子函数）。
这其中，任务或中断内包含的各种算法，普通函数内部的各种执行控制流分支，以及函数内部变量在内存中的分配对于函数的净运行时间都有直接的影响，因而对于系统实时性有着最直接的影响，同时也影响着系统的效率。智能驾驶领域中针对各类算法的优化大多都可以归入这一层级。
典型解决方案：
用于ROS2的开源中间件Eclipse Iceoryx。Eclipse Iceoryx是用于自动驾驶等高安全性应用场景中的一个“零拷贝”进程间通信中间件（Zero-copy IPC Middleware）,是处理自动驾驶系统中每秒数GB数据在多个不同ROS系统节点之间进行传递的“必由之路”。
图：Iceoryx提供的“True Zero-copy”进程间通信原理（参考文献5）
对于用于跑自动驾驶功能的POSIX系统而言，分布在不同进程上的各项功能无法直接访问其它进程的地址空间，必须通过某种IPC方式进行数据交互，而这通常意味着需要对数据（如一幅图片）进行多次拷贝。
由于此类应用中多为图像和点云数据，数据量非常大，这些拷贝操作不仅消耗大量的内存资源，也占用了很长的执行时间，给系统造成了不可忽视的延迟，严重时甚至导致系统崩溃。
而Iceoryx通过在数据发布者和订阅者之间设立共享内存，使得发布者直接将产生的数据写入共享内存，而订阅者可以从Iceoryx这一中间件中获得所需数据的索引（可理解为指针）即可访问这些数据，从而避免了数据的频繁拷贝操作。
（2）基本代码块层级：指一系列不会跳转的连续执行的指令。因此，基本块中的指令将从第一条开始按顺序依次执行，一旦CPU运行时钟确定，其执行时间可以认为就是确定的。如需在此层面优化，只能对代码进行修改。在这个层级上，通常聚焦针对系统会频繁调用的代码进行优化，从而获得明显的整体优化效果。特别对于底层驱动和中断函数，写出最优的代码本身就是一种良好编码习惯和能力的体现。
典型解决方案：
CRC校验算法的优化。CRC校验又称为循环冗余校验，是数据通讯中经常采用的算法，在汽车电子中的应用也非常广泛，AUTOSAR标准中对此也有要求。它可以有效的判别出数据在传输过程中是否发生了错误，从而保障了传输数据的准确性。
图: CRC算法常用生成多项式（来源：网络）
计算CRC校验时，最常用的计算方式有三种：查表、计算、查表＋计算。一般来说，查表法最快，但是需要较大的空间存放表格；计算法最慢，但是代码最简洁、占用空间最小；而在既要求速度，空间又比较紧张时常用查表＋计算法。由于CRC校验在软件运行过程中会被频繁调用，因此有必要对它进行优化，以缩短执行时间，进而获得明显的系统运行效率提升，有利于系统实时性目标的达成。
（3）机器指令码层级：指CPU所能处理的单一指令，各种指令的执行周期通常是固定的。这些指令是由软件编译后生成的，大部分软件调试、追踪、测量工具的分析精度都止于此。之所以单列这一层级，是因为不同的编译器或者同一个编译器采用不同的编译配置选项，所生成的机器指令码是不一样的，因而将直接影响代码的执行效率，进而对净执行时间产生影响。
典型解决方案：
编译器优化。从源代码到机器指令码的编译过程其实存在无数种路径，就像一道数学题有多种解法。通常编译器会提供两种优化目标供用户选择：“资源占用大小”和“运行时间长短”。多数情况下，这两个目标是冲突的，用户必须根据实际情况进行权衡。
目前大多数项目中对于编译器优化的关注都极少，行业内的编译器也主要被国外垄断，极少有企业计划自研。建议大家先从详细研究编译器用户手册开始，通过优化编译后生成代码的执行效率，来逐渐掌握编译器优化技术。
（4）操作码状态层级：每个机器指令均分为取指、译码、执行等多个步骤处理，操作码的状态即指这些步骤。对于软件工程师而言，这是隐藏最深的一个层级了，因为这一层主要涉及CPU架构，而这部分主要由ARM及各大芯片厂商设计。同时，这也是极其关键的一个层级，它甚至决定了系统是否能支持硬实时特性。
典型解决方案：
三种不同的处理器架构WCET对比。现代芯片技术的快速发展使我们不仅仅在更小的面积上实现了更高的运行频率，而且形成了越来越强大的指令集，更长的流水线，更复杂的分支预测单元，具有复杂逻辑的分层缓存，从而提高CPU的处理效率，极大地促进了平均计算能力的永久提升，也就是“更快”。
然而，正是这种芯片架构的复杂性，导致对于同样的代码，最短执行时间和最长执行时间之间的差距也越来越大。
下图定性（而非定量）展示了在三种不同的处理器架构中，某个特定函数的执行时间变化。这些架构均代表各自年代的最高水平，彼此相差20年左右。
图：三种不同的处理器架构WCET对比（参考文献2）
8051是一款经典的嵌入式处理器，既无缓存，也无复杂的流水线。每条指令的执行时间仅取决于系统时钟，因此，最短时间、平均时间和最长时间均相同。
PowerPC 5xxx架构已在汽车领域应用多年，动力、底盘等领域均有广泛应用。它提供了缓存和一条重要的流水线。虽然平均执行时间相比8051已经大幅缩短，但由于受函数开始时流水线的状态和缓存状态的影响，最短时间和最长时间之间也出现了明显的差异。
总结
实时性不一定要求系统跑得越快越好，但一定要求系统是具有高度的确定性，满足功能对于Deadline的要求。对于智能驾驶控制系统，单纯依赖采用高实时性的操作系统并不能解决问题，实时性更应该从系统级进行考虑，基于事件链进行端到端的实时性分析。
下表汇总了影响系统实时性的九个主要层级以及前面介绍的典型优化实例，并列出了常见的分析方法，希望有助于大家采用系统思维综合优化系统的实时性。
欢迎扫码添加作者微信（备注姓名+单位+工作方向），共同交流、探讨。
点击“阅读原文”，进入汽车软件开发专属交流社区
参考文献
写在最后
“知识积累”类稿件质量要求：
A：信息密度高于绝大多数券商的绝大多数报告，不低于《九章智驾》的平均水平；
B：信息要高度稀缺，需要80%以上的信息是在其他媒体上看不到的，如果基于公开信息，需要有特别牛逼的独家观点才行。多谢理解与支持。
推荐阅读：
◆当候选人说“看好自动驾驶产业的前景”时，我会心存警惕——九章智驾创业一周年回顾（上）
◆数据收集得不够多、算法迭代得不够快，就“没人喜欢我”————九章智驾创业一周年回顾（下）