车载处理器如何赋能未来汽车电子电气架构？本文告诉你……

来源:NXP客栈发布时间:2022-11-161040浏览

汽车电子电气架构正在发生深刻的变革。在这一趋势下，车载处理器技术将如何演进？会进化出哪些车载处理器“新物种”？这些“芯”变化将对汽车电子的开发带来何种影响？……想必这是很多汽车圈小伙伴都关心的问题。

在日前由中国汽车工业协会主办的第12届中国汽车论坛上，恩智浦大中华区资深市场经理余辰杰先生发表了题为《车载处理器赋能未来汽车电子电气架构》的精彩演讲，从整车电子电气架构演进对车载处理器的机遇与挑战、恩智浦全新一代16nm车载实时处理器，以及恩智浦车载处理器生态圈支持等几个方面，进行了系统地阐述。

通过这个讲演，大家可以看到，针对上述业界关注的课题，恩智浦已经通过缜密的思考和积极的实践，给出了一个全面的解决方案。我们将本次讲演中的精彩内容提炼出来，在这里与大家分享，希望对大家未来的汽车电子开发提供助力。

电子电气架构是最近大家聊的非常多的话题，下图最左侧，是传统的分布式的架构，逐渐会往以功能为逻辑划分的域控架构转变，比如座舱域、智驾域、多合一动力域、底盘域等等。

更新的架构形态是基于区域控制器的架构，一个区域控制器所包含的功能取决于相邻物理结点的的执行器所负责的任务。举个简单例子，比如车的左前域，可能把底盘，甚至转向功能结合车身的部分功能集成进来。

最右端就是最终形态，整车电子电器架构围绕一个大的中央计算平台，它可能集成了所有智驾，座舱、车身等等需要高算力的任务。然后在边缘测的结点上，就是一些智能执行器了。

▼▼▼

从大的趋势我们看到，无论是从域，或者域结合传统分布式结点的中间方案，还是后面逐渐往区域化过渡。这其中的好处是什么？

首先域架构肯定会使我们的软件更集中，把原来一些可能逻辑类似但分布在不同ECU当中的功能，集成到一个域控制器当中来。同时这样也会使得传感器的输入和ECU之间的数据交互延迟得到优化。还有如OTA升级策略，本来一个功能是分布在几个ECU结点里，现在也会集中到一个ECU中，简化了升级流程。

区域控制器的好处就更直观了，原来一些分布在不同物理位置的控制器，现在被集中到了一个地方。线束重量降低了，原先多个性能较低的MCU被区域控制器中的高算力实时处理器所取代，比如我后面会着重介绍到的恩智浦S32Z/E系列SoC。

汽车工业的一个永恒的话题就是轻量化，比如通过宽禁带半导体功率器件提升动力系统的功率密度，同时电子电器架构的演进导致的线速的长度和重量的减少也不可忽视。而驱动电子电器架构演进的底层动力是处理器性能的迭代。

▼▼▼

在恩智浦看来，无论何种电子电器架构，汽车ECU控制器大致可以分为两个大的平台。一类称之为基础设施平台，我们认为不管低端车、高端车、燃油车还是新能源车，总要有动力控制部分来驱动汽车；车身网络枢纽保障ECU间安全可靠的交互数据；还有车身控制部分，如对门、窗，座椅等控制等。以上这些我们统称为汽车的基础设施平台。

另外一大类，我们定义为可选可且可定制部分，比如有一些车的定位在智驾功能上，另一些车则在炫酷的座舱体验上。这些个性化的功能固然越来越被消费者看重，但从车的本质看并不是必须的。

恩智浦无论在基础设施平台还是在可选部分都有着非常广的产品布局。基础平台上，我们有新近推出的用于动力控域控的S32Z/E，网络上处理上S32G系列芯片也已经被中国众多主机厂和一级供应商所接受，车身控制上从上一代功能安全等级相对低一些的S32K1，到现在最高可支持ASIL D级别的S32K3等。

在可拓展平台上，i.MX系列座舱SoC一直以来是NXP非常强势的一个产品，ADAS 77GHz毫米波雷达上，恩智浦有支持4D成像的最一代S32R SoC产品。

当然视觉上我们也有S32V这样的芯片，它定位在一些初阶智能驾驶或者环视为主的低速场景。后面我会提到，在高阶自动驾驶端，我们在中国已经和像地平线这样的生态伙伴有很深入的合作。

▼▼▼

谈了电子电气架构的演进，谈了整个ECU可以把它分为基础设施平台和可选平台，那映射到处理器芯片上，到底对性能有什么不同要求？

大家可以看到，下图中越往下，也就是越靠近边缘侧的执行器端，它对处理器的需求基本上是高实时性，比如刹车、油门踩下去，你会希望动力变化很快体现出来，这些往往是以实时控制算力为衡量指标的，而这些结点的计算逻辑也都是面向信号的。

恩智浦新进发布的S32Z/E产品，已经不能归类为MCU了，因为它的实时算力已经大大超出了传统的两三百兆主频的多核MCU。所以我们把它重新定义为Real-time Processor——实时处理器，它在图片的中间部分。

当然我们也看到有一些车身区域控制器的设计，虽然他们大多负责实时控制，但也已经有主机厂已经提出了运用SOA架构的设想，不过目前的主流还是以CAN网络为主面向信号的处理方式，强调实时性，对I/O的驱动能力要求很高。

这个也是我想给大家分享的，因为从半导体原厂的角度来看，我们要满足芯片高算力的需求，一直以来的做法是不断迭代先进制程，提高集成度，把核的数目做上去，主频抬上去。但在未来这么做也许会越来越困难，特别是在对类MCU的实时处理器来说。因为从工艺上讲，当传统CMOS工艺下沉到22nm以下时，Embedded Flash很难和数字、模拟部分集成到同一个到硅片上。

我马上要介绍的S32Z/E是基于16纳米制程的，Flash放在哪里？外扩是必然，但你的速率如何保证？当内核达到1GHz的主频时，如果想要XiP，内存接口带宽需要做到多大？而如果只拓展负责存储的Flash，那我们又不得不扩大昂贵的片内SRAM，附加额外的Shadow Flash，这是一种高成本的实现。另外还有I/O驱动能力的问题，16纳米的制程如何做3.3伏、5伏的I/O，对车载控制类应用来说这也是必须解决的问题。后面我会介绍S32Z/E是如何克服这些难点的。

▼▼▼

接下来我讲一下我们今天的主角，S32Z/E实时处理器。如果从传统认知上看，大家可以把这个芯片理解为一个MCU。但这个MCU的算力有了一个质的飞跃，每个核的主频可以达到1GHz，还集成了轻量级的AI的计算能力，可以支持MPC算法，用于诸如自动驾驶系统中的横纵向控制计算。

当然因为它的算力很强，加之丰富的以太网接口能力，相对于传统MCU，它使支持SOA软件架构成为可能。还需要强调的是，恩智浦是业界第一家采用真正意义上的先进制程，也就是16nm这个节点来实现车规实时处理器的芯片原厂。另外，正如我前面介绍到的，S32Z/E所对应5纳米的下一代产品也已经在我们的规划当中。

▼▼▼

什么是实时性？这个概念其实是不太好界定的，大家可以理解为非常快的响应，但这个快是相对的，视应用场景而定。下图中所列出的这些应用被普遍认为是车辆电子系统中实时性要求相对较高的应用。这也就是我们S32Z、S32E所覆盖的应用。

▼▼▼

我前面提到了，S32Z/E的算力有了一个质的提升，核的数目也非常多，最多可以有八个，你可以独立使用，也可以作为四对锁步核来使用。下图左边就是传统的电子电气架构，在这种架构中你可能有一个集中的动力域控制器，下面挂着分布式的独立功能的ECU。

但现在你有了最多可以提供8个1GHz主频的S32Z/E，你可能希望把这些功能都集中到一个控制器，甚至于一颗芯片中来。

不过，即便硬件的性能支持你这么做，但是更大的挑战在软件和系统的认知。对于一些能力比较强的Tier 1，本身开发过这些独立功能的ECU，他们会非常乐于接受这样的芯片，他们可以自己定义一个新的电子电气架构，设计出成本更优化的产品，最后推荐给主机厂。

但是对于大部分的供应商而言，他们很少有机会同时做过这么多控制器，我认为这个时候就会催生出一个新的业务模式，我把它称作就是“软件即产品”。即出现一系列专注于某类应用上层算法的软件供应商。当然，要支撑这种软件业务模式，硬件上除了要具备高算力之外，还需要有虚拟化和隔离机制做支撑，使得不同的应用程序互相不干扰的运行。S32Z/E无论从内核还是SoC架构上都设计了必要的虚拟化隔离机制。

▼▼▼

下图是S32Z/E整个芯片的框图，大家可以看到，它的主要计算部分有若干个Cortex-R52的组合，有四对锁步的Cortex-R52，它是主要被用来做业务逻辑的。还有一个深蓝色的Cortex-M33的锁步核，我们称之为System Manager，它可以被用来完成一些系统功能，比如做Secure Boot，或者做整个芯片系统的功能安全监控等，和处理主业务逻辑的Cortex-R52完全隔离开来。

计算部分，我们还集成了一个DSP核，可以完成一些轻量级机器学习业务，主要针对ADAS上的，比如基于MPC的横纵向控制算法，因为它往往需要很多的浮点算力，如果是要跑在传统的逻辑核上面，它效率是非常低的，因为Simulink MPC Toolbox生成出来的代码很多是基于Vector C的库的。

再来看网络安全引擎HSE——S32Z/E集成的HSE加密引擎支持目前业界所有主流的对称和非对称加密算法。这里还要重点介绍一下S32Z/E中集成的一个网关子系统，称之为FlexLLCE，它是由两对四百兆主频的M33核负责调度，通过一个CAN Hub支配24个CAN Controller组成的一个的CAN网关子系统。所有的CAN网关相关的功能，可以完全在这个子系统进行闭环处理。

还有我们集成了博世最先进的GTM4.1，这是用来做高精度PWM输出的，主要应用场景包括发动机喷油点火，新能源汽车的主驱控制。当然我们也有TSN支撑的以太网接口。

最后说一下存储器部分，因为这是一颗16纳米制程的芯片，以目前的工艺水平无法集成Embedded Flash，所以我们需要一个额外的Flash Shadow放在外部，我们在系统初始化时会把存这个Shadow Flash里面的程序，直接加载到内部高达19MB的SRAM里面去。这样做的好处显而易见，因为SRAM的运行速度肯定会快。我们还会提供LPDDR4以及Hpyerbus 接口，可以方便用户灵活拓展高速存储介质。

下图右边的S32E2，是S32Z2的一个升级，它主要弥补了S32Z2对5V模拟I/O支持不足的问题。

▼▼▼

恩智浦公司作为全球领先的汽车处理器供应商，在芯片底层软件上的投入是非常大的，无论从MCAL、HSE Firmware，还是一些私有的网络加速器IP的驱动上，恩智浦都投入了大量的研发资源。

但这并不意味着在“软件定义汽车”的新时代里恩智浦会成为一个软件公司，事实上我们也只能聚焦在和硬件最紧密相关的底层软件上，这就是为什么我们需要一个很强大的生态。比如在AUTOSAR软件中，MCAL和HSE Firmware只是和硬件相关的驱动层，而整个AUTOSAR框架中大部分模块是和硬件无关的上层协议栈。

过去我们依靠Vector、EB这类国际软件供应商为恩智浦全球的客户提供这类软件，今天我们在中国也有像普华、东软这样的优质生态合作伙伴专门服务本土客户。另外和硬件生态合作伙伴上，我们也有非常多的实践，比如在高等级自动驾驶方案上，我们就选择了和地平线公司合作，一起开发了基于地平线征程5和恩智浦S32G的Matrix Superdrive参考设计，该方案也已经被许多中国主机厂所接受。

恩智浦作为一家深耕中国市场的外资芯片原厂，一直把拓展本土生态圈作为工作重点。我们深信恩智浦在中国的成功离不开本土生态合作伙伴的支持和帮助。

▼▼▼