从芯片原厂的视角看自动驾驶软件生态

喧了个荒

从芯片原厂的视角看自动驾驶软件生态

Tracy Yu 恩智浦
汽车软件的生态现在越来越火，如软件定义汽车、新型电子电气架构，包括AutoSAR软件等。但是，所有的软件都是承载在硬件之上，从芯片原厂的视角怎么看待这样的软件市场呢？
乔布斯曾经说过，如果你真的很关注你的软件，你就应该做你的硬件。这句话最早是面向对象语言的先驱Alan Kay说的。他当年在用早期的大型电脑浏览时觉得很不方便，所以他要做一个硬件。但现在反过来了，更多的硬件厂商想去做软件。
硬件是一个很宽泛的概念，不单指一台计算机，一个芯片可以是一个硬件，一个汽车也可以是一个硬件。很多主机厂建立了很大的软件团队，一些是集中于自动驾驶的全栈自研，也有很多在做娱乐系统、基础软件，比如最有名的大众的软件部门，在软件定义汽车角度走得比较领先。
硬件的发展演进
在芯片方面，车路协同包括车端和路端，车端不管是基于什么无线装置，通过路端的基础设施实现通信，都要通过ECU或T-Box连到车中，通过芯片来实现。
从硬件演进看，芯片的发展趋势首先是工艺制程，很多MCU已是16纳米，MPU已经达到5纳米，像ADAS或人们熟知的英伟达、高通都在7纳米节点，正在往5纳米走。
MCU传统意义上都是200MHz、300MHz的单片机，以前是90纳米、55纳米，现在很多是40纳米，最新一代很多的28纳米，恩智浦最新的S32C和E产品线是16纳米。所以，最先进的MCU已经不能称之为MCU了，恩智浦重新定义它叫实时处理器，是具有运算能力的处理器。
从架构上看，多核大多是8核12核24线程或更多。汽车是成熟工艺、成熟制程，经过验证后再往车规工艺上做，满足了更高的可靠性后，再往车规上用。但多核并不总是能解决问题，核多了软件不可都能并行运行，而且核多了功耗、散热和内存墙各种问题怎么解决，所以多核并不能完全把算力提上去。
汽车还有一个比较突出的问题是功能安全，早在功能安全之前就有一些类似概念，比如ECC内存。在功能安全提出后，很多保护硬件或监控硬件故障的机制都被归类到功能安全硬件的范畴。


功能安全不只是常见的内存校验技术，还需要一些冗余，甚至包括DMA锁步等异构概念。单纯CPU核不能解决很多问题，只能处理逻辑，比较擅长线性任务，如浮点运算。现在更多是AI神经网络和AI加速器，需要用从MPU到MCU的异构实现网络加速器，特别是域中的区域控制器，实现传感器信号在确定的时间内的迅速传输。
例如区域控制器网络加速，毫米波雷达有非常多的信号，它本身不做处理，而是通过CAN FD接到一个总线，最终送到中央ADAS域。需要保证信号传递的实时性，能够让ADAS域控中的SoC及时准确地计算，所以，要有一些硬件加速机制。
虚拟化和多核也有关，单片机上核多了，需要集成不同的功能。在设计之初就把相应任务所要占用的CPU资源、内存资源、IO资源都规划好，再通过软件锁方式防止互相访问的干扰。利用一套更先进的provide机制等先进方法论有助于开发人员只关注应用业务，而无需关心具体怎么处理IO访问的互相干扰和内存的越界问题。这样做的前提是要有实时的硬件支撑，否则开发是便利了，却消耗了太多软件资源，占用太多CPU带宽，反而导致实时性降低了。
16纳米产品线采用最新的ARMv8-R52架构的虚拟化框架，有很多虚拟化机制，不仅是核虚拟化、内存虚拟化、外设虚拟化，I/O虚拟化，中断虚拟化等等。
早期嵌入式平台的广泛应用取决于内存技术的发展，现在90%的汽车单片机都有E-flash，片芯上有嵌入式内存，采用完全不同的工艺，甚至是高压工艺，因为新能源汽车是400伏、800伏高压。
随着工艺的下沉，实现了更高的算力、更低的功耗和更高的集成度，但目前节点没有车规嵌入式内存工艺，而是在一个封装中再封一个专门的内存片芯，其挑战包括功耗、可靠性、成本和散热。
最后是安全和数据加密，硬件上也需要有一个加密引擎，以实现更新、验签程序是否合法。
软件的发展趋势
软件的发展趋势在于，现在无论是Tier1还是OEM，都在用独立于底层硬件的AutoSAR架构开发软件。在没有统一标准之前，一些组织联合大的车厂定义了一套标准化接口的软件框架。为了应对硬件的发展，需要在一个SoC上运行多个应用程序，即多核操作系统或Hypervisor，如果把多核当成单核来用，效率会低很多。


在安全方面也有很多硬件机制，需要启用硬件机制的安全框架（安全库），发生故障时还要反应哪些硬件上电之初要检测一遍，哪些程序跑起来要进行周期性模拟，哪些下电之前要检测一下，都要有一套统一的安全框架策略（HSM固件+OEM/区域特定服务）。
另外，用于现代EE架构和软件方法的TSN和SOA中间件，以及优化的应用程序和硬件相关驱动程序（CDD和例如数学库）也必不可少。
恩智浦在这方面提供了一个跟安全相关的完善软件，包括加速引擎固件、加密算法驱动，包括一些OEM自定义的加密算法，还有确定性时间通信TSN，以及SOA设计方法。因为ADAS或智能座舱的芯片算力更强，引入了更多先进的开发理念。
还有用专门硬件处理专门业务的网络加速器，例如，处理一个小的CAN子网络，传统做法是很多CAN IP，每个IP对应一个物理CAN通道。如果没有加速器，用这个网络实现CAN通道1到CAN通道2的路由，就相当于一个没有DMA的内存搬运，要经过CPU对报文拆包、解包，很长的协议栈都要经过CAN通道输出。加速器是一种非标IP，下面可以挂很多CAN，其中有一个CAN HUB，路由表再放一个M33或M0+核。
Tier1等终端用户自己去做非标并不现实，为了保证这一代加速器沿用到下一代硬件，能够跨平台使用，就要提供很好的软件、很好的生态，方便客户使用。
恩智浦去年量产的S32G芯片同样是用来做网关，迎合了区域架构的趋势。现在的网关要求越来越高，CAN通道包括16路加速CAN，还有非加速CAN；功能安全引入了A核锁步，M7核也会锁步，除了锁步、内存自检、数字部分自检，还有错误故障的收集模块，类似于log step DMA，对应的是非常复杂的软件，比如核也是异构的，可以跑Linux、QNX，MCU核上跑传统操作系统，不管是不是AutoSAR，加速器要有为它优化的驱动。


恩智浦还提供软件框架和各种软件，包括硬件加速引擎固件、加密引擎固件、网络加速器底层驱动、以太网加速器驱动、以及标准Linux BSP、车身IO驱动、IPCF核异核通信框架。
最早AutoSAR刚刚提出时，硬件原厂并不是很买账。所以，早期跟硬件相关的软件都由第三方去做。在加速器驱动器上有RAM核，RAM核可以跑实时、非实时操作系统，还有虚拟化机制的虚拟机，还有各种中间件，原厂不太会覆盖这一块，当然也要看怎么来定义中间件。


从下面往上都是中间件，AutoSAR堆栈除了M核，可以都叫做中间件，不算操作系统，往上全都叫中间件。往下是APP程序，现在还有很多人不把它叫中间件，把上原子服务层，包括各种标准化的车身服务、网络服务、ADAS服务；也有把一些通信软件叫中间件的，比如TSN中间件等等，但是大部分硬件厂商都不会介入的太深。
应用层更是这样，先进的开发理念是Tier1做好硬件和底层软件，主机厂或算法公司把应用层程序优化好，最终有一个系统集成商进行集成。应用很普遍的典型模式是，ADAS感知算法来自一家，中间件可能来自另一家，底层的操作系统可能又是另一家来提供，最终有个大的系统集成商把它们集成起来。
特别是涉及到一些控车的功能，每一块都不同业务领域的人做，很难找到一家公司能够把它都包下来，最后只有主机厂自己的内部团队可以来做这件事情。目前，大部分是主机厂自己成立一个智能驾驶研究院，做高精定位地图、车路协同、GNSS、IMU等，将这些东西输出给车机端，也可以是智驾域，最后进行集成，也只有主机厂才可以把它兜起来。
所以，这里有一句话：“对软件极度较真的人，应该生产自己的硬件”（People who are really serious about HARDWARE are building their own SOFTWARE）。至于汽车软件生态系统，L2+车辆中有超过10亿行代码，从应用程序和架构看，应用和参考中间件包括：BMS、照明、电机控制中间件；集成PMIC/模拟驱动器；通信栈（TCP/IP、AVB/TSN）。未来车辆架构参考软件包括：云平台车辆集成平台、FOTA/数据分析、域和区域中间件框架。
易用性方面，完整而强大的支持有助于加速开发，包括：具有通用代码库的AutoSAR和非AutoSAR实时驱动程序（RTD）；所有S32x平台设备的安全固件标准；IP加速器的复杂驱动程序；跨Arm Cortex内核支持RTOS和应用程序操作系统。
还包括加快客户上市时间项目集成的全套工具：S32DS IDE、S32配置工具、MBDT、AMMCLib、FreeMASTER；高级安全软件框架（SAF）；安全核心自检（SCST）；eIQ自动AI/ML推理引擎。


最后，我觉得有一句话很有意思：如果硬件是问题，软件就是答案。复杂的软件太多了，要认认真真建立自己的软件生态，让更多的软件伙伴围绕硬件参与进来，愿意为的硬件提供更多的服务。

成逸

我了个去，顶了