谈谈下一代EE架构的局限

自动驾驶在新一代EE架构中趋向于从分布式向集中式演进，在此过程中，整车需求包括机械、电气/电子、软件、热学等。工程师需要从中提取电气/电子方面需求，并且对其进行分解然后协调各下游部门进行开发设计。在整个过程中，涉及电子电气架构的定义、设计和交付的各种工程师必须平衡相互依赖的需求。从传统架构到智能电气架构，也会面临类似的问题——传统电气架构全部都是机械和电气范畴内的，在OEM那里是属于电气部门的，和电子不搭界，但升级到智能电气架构后，全电子化了。因此可以说，传统电气架构的可靠性下限比较高，但上限很低，而基于半导体方案的智能电气架构，可靠性下限比较低，但是上限非常高！

EE架构基础软件问题

这里我们需要说明的是，如上过程从整体上看确实是有利于整个系统设计开发过程的。因为集中式域控制器工作过程中，其资源分配和任务调度也更加灵活。模块化的软件开发也将更加有利于整个系统的分布开发和在线升级。然而，区域控制器是根据车辆的物理布局将其余功能整合在一起。区域控制器的实施通常需要对软件和供应商交互进行很大的更改，这对汽车制造商和供应商都是一个很大的挑战。

整体来说，区域集中式架构通过实现超强的算力和更大通信带宽的支持。最终，通过标准化的API接口可以实现软硬件的真正解耦（也就是实现面向服务的SOA架构）。但是，由于SOA这一思想本身来自于互联网，在原有电脑端高并发的场景应用中，更加倾向于数据传输效率，而非可靠性。

那么，我们就要说SOA架构对于下一代自动驾驶的适配性到底咋样？由于自动驾驶汽车需要使用大量传感器，车内线束也在迅速增长。车内需要传输的数据量激增，同时线束不仅承载的信号更多，而且数据传输速率要求更快。

因此，车端的SOA则在保持基础传输效率的同时更加关注可靠性。那么如何提升这种可靠性和执行效率则是下一代EE架构必须面对的棘手问题？

首先是域控制器内部，应该在满足最低限的算力需求情况下，尽可能提高算力利用率。这时候，各个芯片的AI处理能力和逻辑处理能力就显得尤为重要了（这一点将在后续进行详细讲解）。此外，我们清楚各个SOC外围往往会接入一定量的存储单元用于对启动程序、操作系统、临时交换数据、即时处理数据的存储。这一过程是为了方便SOC单元能够在额定时间内随时存取相应的数据进行处理。因此，对域控的整体性能来讲，大容量的存储单元对于提升SOC运算效率是非常重要的。当然，考虑到成本问题，各存储器的扩容参数也不能无限放大，需要根据实际仿真或者台架测试参数来定。此外，域控内的通信线路中可以多接入大带宽的通信总线，比如接入PCIE可以多用于传输原始数字图像或点云；加入更大容量的以太网（如千兆以太网甚至万兆以太网）也可以大幅提升数据传输性能。

如上只是SOA中的单级域控单元的控制策略，当然其思想对于多级域控来说也是适用的。从本质和局部提升整体架构变革带来的问题可以提升架构升级后的适用性。

通常，SOA的软件部署都在MCU上，因为通常需要提供一个实时、高功能安全等级的系统和芯片，才能确保SOA的软件部署实现最优内部进程过程通信能力（Inter Process Communication）。这里的IPC主要包括常用的SOME/IP、DDS、Dbus、MQTT等。

EE架构核心域控数据交换的媒介——Switch交换机

先进的电子电器架构中由于往往承载了各宗智驾域内的传感器，域控制器和黑匣子等零件的链接与信息交互，而真正的交互过程有并非是点对点的，所以整个过程需要专门接入交换机进行数据交换和路由。因此，“交换机”的作用则是不仅串联了各硬件总成，更是为各端口之间提供了有效的网络数据转发、虚拟网络划分、链路聚合等功能。

对于先进架构来说，其交换机类型可以分为控制器内部Switch和外部Switch两种。这两种交换机均是工作在OSI参考模型中的数据链路层。对于先进的自动驾驶架构来说，交换机需要在满足基本数据通信及转发的基础上，同时提供适当的时间同步、调度延迟处理、资源管理及可靠性保证。

这里我们对其中的几个重要的方面进行详细说明。

-Switch数据播发机制

先进的自动驾驶会采取冗余的EE架构设计，从内向外无论是域控制器内部还是域控制器之间都是采用了包含传感器、执行器、通信、电源等双路计算交互方式。比如，域控制器内部对于传感器数据的处理，通常是多SOC均接入某一类传感器数据进行数据处理、融合。这就意味着，输入的传感器数据会通过交换机传递至不同的SOC。当然，这里的传感器数据类型可以是原始数据RawData，也可以是结果数据ObjectData。不同的传递方式会依赖不同的传输介质及交换机，比如原始数据是依赖于PCIe Switch传递图像，结果数据是依赖于eThernet Switch传递环境目标信号。交换机工作的方式有单播、广播和组播的方式，通常情况我们为了实现资源利用率、效率和可靠性的最大化，会选择带有组播优势的Switch。因为，这里组播方式的Swicth相当于“点对点订阅”所需要的信息，既避免了单播无法全面的找到适配的接收端的弱点，又可以规避广播中对于交换机存储和CPU处理能力的极大挑战。

-Switch时间同步机制

先进的自动驾驶EE架构中主要以以太网作为主干网，为了提升数据交互的实时性、安全性，通常会考虑将智驾域控与其他域控通过以太网交换机进行直连，且关联的每个域都会有自己的交换机。各域控之间的交互都会考虑一定的时间同步性，然而，为了更好的适配整个架构，需要增加时钟冗余和时钟传输路径冗余，同时对满足车辆功能安全的需求，需要提供一种统一的解决方案。交换机在整个域控内部及域控之间都可以看成一个边界时钟节点。即传递至接收端的帧信息不仅有数据还应该有时间戳信息，这就使得收端可以定期的进行时间同步。并且，由于Switch具备一定的存储转发功能，因此，当主时钟失效的时候，还可以通过存储的时钟信息起到一定的缓冲作用。这里要说明的是，很多网络设计师会考虑采用时间敏感网络TSN中相关时间同步协议802.1AS/802.1AS-Rev进行Switch同步规范。

-Switch中的调度延迟处理

Switch中的调度延迟也可以理解为传输延迟，也就是说，对于Switch来说，智驾域输入需要传输的数据可能是五花八门的，当然每种数据也可能本身从重要度、紧急度、轻量化等方面具备一定的优先级。那么这种数据转发的优先级我们希望是能够被Switch所识别并处理的，怎么做呢？那就是在交换机多个待输出队列中识别VLAN或IP所代表的优先级队列，利用循环列表的方式来控制每个队列的开关时间窗口，调整时间感知整形器，通过灵活配置来实现不同延时需求的调度规则集合，配置过程可以是优先级抢占发送资源的过程，即高优先级在传输帧中抢占低优先级发送数据，从而减少不同数据帧的最大传输延时，确保实现传输延时确定性和带宽的稳定性。

-Swtch资源管理与可靠性

传统的CAN网络通信具有天然的组播通信方式，某一个节点的故障不会中断其他节点间的通信。先进的自动驾驶系统最看重的就是功能安全的实现，而功能安全在应用汽车以太网作为骨干网的拓扑中主要关注的是通信安全。通信过程中往往需要大量的数据转发的网络拓扑，这些都是由交换机作为承载单元实现的。

我们前面提到，只有组播方式的信息交换和播发是最可行的。可以说，面向未来的集中式EE架构是在基于以太网基础上采用了集中式的点对点通信实现的，这就需要使用一定的消息队列来缓存一定大小的报文和控制通信信息。并且，考虑功能安全所关注的通信安全，则要求该以太网Switch利用软件或者硬件冗余通道来保持实施数据备份。笔者了解到，很多车身网络工程师采用了TSN协议中的802.1CB规范来设计硬件线路和软件流量的双重备份，这种类似复制帧的方式有效地提升了功能安全等级。

硬件设计问题

- 配电设计

从传统架构到智能电气架构，最大的变化就在于很多原始问题由大量的机械问题变为电子电气问题，对于排查故障要求也变高了，并且很多都是涉及电气部门的电子问题。可以说，是从纯硬件升级到软硬兼施的问题，并且问题主要以软件为主。既然是电气问题，那就不得不提到相关的电源分配问题。

为什么要提到电源呢？因为，升级后的自动驾驶域控通常都是采用独立电源供电的方式进行配电。整个域控负载需求提升以后，很多都会考虑气能量管理、上下电策略、负载类型、负载特性、保护特性、线束匹配、散热/防护设计、连接器设计、PCB载流等。也就是说这些都是整个域控电源和电流的设计很大程度上会影响其输出效率甚至安全性。那么，我们在做架构设计时，就需要充分考虑在需求中增加配电能力和保护措施，比如通过在域控芯片中增加保护功能（大电流Shunt）和诊断功能的电路实现。

因此，对于主机厂来说，在做Tier1的招标时，一定要同时考虑其是否具有配电设计能力和电子模块的设计能力。这也是最可能实现电气架构落地的必要条件。

-芯片问题

提到车载智能芯片很多人首先会想到的是自动驾驶相关的AI芯片（又称MPU）和逻辑运算芯片（又称MCU）。当前研发的重点在于基于域控制器的整体设计、开发，将其中的算力、带宽、功率及软件算法等作为主要的考虑的选型要素。然而，一个自动驾驶相关的芯片还需要统筹考虑到模型适配性、算法运行效率及其安全保障等。其中算法模型适配性需要进行模块和进程分解，而运行效率则包括进程数据通信、深度学习模型加速、任务调度和资源管理等。而功能安全保障能力有需要更多的场景分析和系统测试。这些都是比芯片本身更消耗人力、物力和财力的。

举个例子，应用在ADAS中的系统芯片，大多数在ASIL-B或C级，为了提升功能安全等级至ASIL D,多数OEM会将多片B和C的芯片建立级联关系的内核冗余技术，这种技术能力对芯片设计的要求很高。对于某些搭载在单个域控制器芯片的算法而言，由于为了实现高功能安全等级的中央计算能力，其核心实际是在主内核中配备一个影子内核，两个内核需要同时执行相同的指令，再利用比较器比较出两者差异，一旦两个中的内核之一出现计算错误，比较器就会启动纠正措施。

如上图描述了一种基础的软件错误校验框架。主SOC和影子SOC都运行相同的SWC软件模块，主要SOC运行端通过硬件及软件模块的运行日志错误搜集器分别搜集其芯片运行的错误情况并通过Error Reports报告给整体的系统错误处理器。该处理器有两种错误信息处理方式。其一，是同时接收影子SOC所同步运行的SWC结果，并通过比较器进行误差识别和矫正。矫正后的内容通过关键失效处理器对其中的关键失效内容Critical Failure进行处理，处理完成的结果可以发送给MCU进行终端失效处理。这类型处理模式实际上是对其进行了双重保护，确保整体的失效带来的不利后果降低到最小，这就无形中提升了整个芯片架构在功能安全上的能力。

但是，实际应用中，这种锁步功能的软件模块并不是很容易实现，多核锁步的这种安全架构方式会加大成本与片上系统功耗。锁步架构对于芯片的设计能力要求高，很多芯片设计能力出众却缺乏汽车电子领域经验的厂商却十分重视这块的能力，也试图参与ASIL D级MCU芯片市场的竞争。

此外，一个域控制器中的自动驾驶内嵌芯片可能会涉及深度学习模型的实现、合适逻辑算力的CPU、具备图像渲染功能的GPU、数字信号处理DSP芯片、图像信号处理ISP芯片和CV（计算机视觉）芯片等。在芯片基础上，还有一个支持深度学习模型实现的编译器，该编译器需要开发来最大效率地提高芯片的利用率，避免处理器等待或者数据瓶颈堵塞。如上，具备挑战性的问题包含如下三个：

1）如何在模块和进程分解中将算法进行适配？

2）如何在进程数据通信、深度学习模型加速、任务调度和资源管理等方面提高自动驾驶软件的运行效率？

3）如何通过设计合理的工程架构（如开发系统冗余模式）提升在功能安全/预期功能安全的保障能力？

域间交互问题

为何单独提到域间交互呢？这是因为，对于下一代自动驾驶系统EE架构上，很大程度不再像传统信息交互那样，通过电信号直接发送给执行单元，驱动机械端执行相应的指令信号。对于很多主机厂来说，发展下一代自动驾驶系统，往往需要在执行效率上提出更多的要求，因为诸如各类碰撞危险的场景往往都是在一瞬间就发生了。这一需求的提出使得主流主机厂将更多注意力倾注在滑板底盘技术（这里的滑板底盘涉及包括制动系统、转向系统、驱动系统和悬架系统）上。原因是其具备响应速度快、控制精度高、能量回收强的特点易于使用逆向工程实现改装，是实现自动驾驶不可缺少的零部件。

通过将底盘域中的所有节点并联至整车域控制器VDC，整个控制可以实现整体模块化，控制管理效率上也是极大的提升。可以说，滑板底盘技术的安全性对于下一代自动驾驶执行控制来说，是最基础最核心的要素。我们知道对于顶层自动驾驶系统开发来说，下一代系统更加追求模块化、软件定义和软硬解耦，这可以减少零部件和硬件带来的边界限制。这一点上讲，对于滑板底盘也适用，通过将制动、转向、三电、悬架等进行模块化布置，可以使整个底盘拥有更高的灵活性，且分布式驱动算法升级可以实现更安全的底盘功能，实现“滑板底盘”的功能。

这里需要注意线控底盘技术虽然有如上各种优势，然而，这一先进的技术也会面临电子软件或硬件故障所带来的各种隐患。这相对于曾经的纯机械式执行控制系统来说，却是拿执行效率换取执行可靠性，对于功能安全要求高的场景来说还是十分不利的。

因此，为了规避如上可能存在的风险，也只能在滑板底盘软件算法和分布式硬件部件上创建多重冗余，才能保证在故障情况下维持住其基本的执行器功能。这里的冗余正是之前在L3系统设计中强调的双冗余执行系统。如ESP制动过程通常会搭载主ESP控制器，也包括冗余控制器iBooster（博世）或MKC one（大陆）等；又如EPS系统中部分厂家如捷泰、奈斯特、万都等转向供应商就开发了双控转向系统。

总结

软件定义汽车时代的兴起，需要一种集中的、抽象的、强大的计算架构，这就需要一种新的系统硬件架构来完成这一使命。以服务导向的软件系统构架（SOA）将成为主流，以SOA/SOME-IP为脉络支撑起汽车以服务为出发点和差异化竞争的整车E/E架构。在经历功能域控、区域域控等阶段后，将催生真正的汽车大脑：中央计算单元。并与MEC（多接入边缘计算）以及云计算组成协同式解决方案，避免车端算力需求无限增长。但是，这类集中式架构却在过程中存在一定的固有缺陷。在架构设计过程中需要十分明确的关注其中的不确定性因素，避免产生一些不可预知的后果。