几天前，我回答了一个关于汽车行业编写代码的问题，这引起了很多争议。因此，今天我想谈谈汽车行业软件的现状。

之前有人问我，汽车行业有码农吗？

事实上，在过去的机械控制时代，汽车行业确实没有代码农民，但多年来，随着电气化和智能化的深入发展，汽车行业对软件工程师的需求越来越大。

汽车软件属于嵌入式软件开发，与互联网行业的软件开发大不相同。

汽车软件开发的特点

一、基于模型的开发MBD

MBD的全称是Model Based Design，基于模型设计可以节省开发时间和成本。MBD 主要优点是：

1， 图形化设计

大多数汽车软件都是基于模型的软件开发。这在大公司尤为明显，我们使用它Simulink将要实现的逻辑用图像的形式表现出来。图形设计逻辑清晰，交流维护方便。对于第一个代码作者和未来可能的作者，他们只需要理解图形，就可以知道代码实现了什么功能。而且如果不看图片，再看几千行代码是很费时的。

图形设计

对于软件工程师来说，最重要的任务是实现算法。例如，我现在有一个自适应巡航系统。汽车需要根据前面的位置和速度来确定跟踪速度，以及是否切换跟踪目标。这些决策的过程是逻辑判断，需要软件工程师设计。

2， 自动生成代码

在模型开发中，图像算法最终依靠工具自动生成代码。代码效率显著提高，手动代码耗时长，容易出错。只要工具使用方便，自动代码就不会出错，质量高于手动代码。

二：代码书写标准统一

无论软件是自动代码生成还是手工书写，都需要遵循一定的标准。为了规范软件形式，汽车行业提出了许多统一的代码书写标准，如我们所知道的MISRA标准。

MISRA C Coding StandardC编程规范是工业标准，全称是 (The Motor Industry Software Reliability Association 汽车工业可靠性联合会) ，成员包括大多数欧美汽车制造商。

该标准包括大约100个C语言编码标准，旨在帮助汽车制造商开发安全可靠的嵌入式软件。一些编码标准让其他行业的代码农民看起来很荒谬，比如以下内容：

Rule 1: 三元操作符不得使用；

Rule2： 所有标识符不得超过31个字符；

Rule3:注释代码不得残留；

Rule4：不得使用goto以及continue；

如果你完全按照这个标准写代码，你的代码是可读的、可靠的、可移植的和易于维护的。遵循这个标准也可以管理代码的质量，但是Misra标准过于严格，一般企业会根据实际情况执行。

三、软件架构的统一

由规范编写代码，软件架构更加统一规范。

这就是AUTOSAR(AUTOmotive Open System Architecture 汽车开放系统架构)。

AUTOSAR该联盟由欧洲和美国的主要汽车制造商成立，致力于开发一套支持分布式、功能驱动的汽车电子软件开发方法和软件架构标准化方案，以应对越来越复杂的汽车电子系统。汽车在电气化、智能化的背景下ECU日益增多，迫切需要一套全新的整车软件设计标准来应对复杂的设计，使基本的软件元素，接口和总线系统能够实现标准化，降低开发成本。

通过AUTOSAR车车载网络、系统内存和总线的诊断功能进行深入管理。AUTOSAR主要有三个分层设计目标：

1， 建立独立于硬件的层软件架构

2， 提供方法论，包括制定无缝的软件架构堆叠流程并将应用软件整合至ECU

3， 制定各种车辆应用接口规范，作为应用软件整合标准，方便软件构件再不同汽车平台复用

AUTOSAR整体框架为分层式设计，以中间件RTE为界，隔离上层的应用层以及下层的基础软件层。

AUTOSAR三层架构

AUTOSAR的优点在于可以模块化设计，并将“配置”的理念深入到软件开发中，真正让软件变成可设计的，能即插即用的软件结构。

汽车行业与互联网行业软件开发区别

经常看到一些观点说汽车行业是传统行业，保守；互联网行业是新兴行业，创新有活力。

就连同为造车的新公司都忙着和传统汽车企业撇清关系，说我们是造车新势力，互联网公司。。

相比互联网行业软件能够快速迭代开发，远程升级；汽车行业只能按部就班走流程来设计软件，因此汽车嵌入式软件是为互联网的码农所不齿的，因为我们开发速度跟不上互联网速度。

想来想去，两个行业的软件最大的区别是什么？是代码数量还是架构不一样吗?这些只是技术层面的东西，我觉的是汽车软件更侧重安全和可靠性。

互联网的软件，如果有bug，只需要后台进行推送更新升级就行，顶多造成使用不方便，一般不会有人生事故和财产损失。而汽车软件是容不下一个Bug，以及任何有歧义的代码。软件有问题轻会影响汽车正常使用，重则会造成生命财产安全。

而且，软件造成的问题后期保养维护很麻烦，需要安排大量人力物力进行售后，这对于汽车公司都是巨大的财产损失。

所以汽车软件必须小心翼翼，按照以下方法来干活：

使用自动代码，因为机器往往比人靠谱，不太会犯错；

即使手工代码，也严格按照汽车行业标准来书写，保证没有歧义，没有意外的情况发生；

在开发过程中，我们也按照ASPICE流程来指导我们的开发和测试，保证软件符合需求，并且质量过关；

同时，汽车软件还有功能安全来进行冗余设计，防止软件可能的故障造成无可挽回的后果。

也就是因为汽车软件开发有这么多条条框框需要遵守，每一个软件使用前都有这么多流程需要走完，因此，汽车软件基本就跟“快速响应”，“迭代开发”这些名词无缘了。

所以我们一直被造车新势力称为“传统造车企业”。

汽车行业软件工程师都是些什么人

目前汽车行业无论是传统ECU开发，混动/电动控制器/自动驾驶都离不开软件工程师。不过汽车行业的码农不同于其他行业，这个行业要求码农们不仅仅要精通代码，还要有以下技能树：

1， 对汽车/受控系统要十分了解。无论是传统车还是自动驾驶系统，都需要对汽车有一定的了解，不然无法开发控制算法。而汽车又是个十分复杂的机械系统，不是临时看看资料就能了解的，因此汽车行业的码农都需要有一定的机械学科背景。

如需转载，请联系本作者：汽车搬运工王先生。

一．传统汽车的软件现状如何？

互联网人看传统汽车的软件，就像普通观众去博物馆看看考古发掘。这么又老又笨的系统怎么还在世，还没被革命呢！在新四化的趋势下，传统汽车的软件发展仿佛是口诛笔伐的旧社会代表，被无数进步势力不断diss。然而，拥有这些老掉牙软件的传统汽车却像野草一样，不但没有没落，而且还在扩张领地。对于比较新潮的互联网软件，传统汽车似乎完全不搭界。

那么传统汽车真的有软件吗？如果有，这样的软件还有生命力吗？传统汽车的软件发展，怎么这么慢？

只要你知道什么是手机就知道什么是“软件定义汽车”，以及为什么这个事有必要，却又为什么很难，必须上升到战略层面来看这个问题。

假设你有一手机，可以刷个弹幕，拍个照，吃个鸡。实现了多样化的功能，而这些功能的切换，更新往往在几分钟里面就完成了。
假设你有一汽车，可以听广播，你说那能不能，让这个车跳个舞吧，假设车厂认可你的需求，保守估计你得等个2年

客户爸爸已经越来越不能满足车辆功能的开发周期，期待更快的功能迭代，而车不能满足这个需求。当有一个车厂开始干了这个事情。其他车企就是隔代的竞争，这就是为什么会有“软件定义汽车”，核心是应对客户日益增加的迭代需求。

传统车辆上的结构就是以CAN网关为中心的多个独立小控制器，车厂的工作简单来说就是定义好要什么功能，然后一个功能让供应商给个小控制器，然后供应商告诉车厂，我的控制器要正常工作，什么信号进，什么信号出，然后车厂设计到整车DBC中**（后面我会讲，不要让DBC工程师随便改需求，他会杀了你的）**最后车造出来，你就可以用上这些功能了。

然而客户说明天我就要一个新功能，噩梦就开始了。

这里有几个关键点需要高亮出来：

1. 控制器非常之多，且全部由供应商各自管理自己的软件和硬件
2. CAN和CAN网关可以理解为是一个公共协议接口，任何调整都会影响到所有其他控制器
3. 控制器都很难单独连接到互联网，都需要逐个单独连接进行更新。
4. 一个功能，涉及到多个控制器一起调整，各种供应商会相互制约。

这些约束就导致了，车辆无法快速的进行功能迭代。

那手机软件又是如何做到如此快的功能迭代的呢？SOA架构又是什么？

• 整车代码量和复杂度增加

对比于传统汽车的 “三大件”定义汽车，消费者关注于发动机、变速器和底盘。随着汽车不断走向智能化和网联化，消费者将开始关注差异化和科技感的配置，功能的实现严重依附于软件，因而汽车代码数量和复杂度也日益增加，软件在整车的研发成本也越来越高。

• OEM研发模式的优化

站在OEM角度，需要OTA来实现功能的完善、算法的更新、BUG的修复和成本的优化等。另外在激烈的竞争下，硬件利润空间在不断压缩，OEM参考消费级产品靠售后的软件及服务收费分摊一次性硬件成本的模式，开始在售后软件生态、技术付费上进行探索，需要消费者来为自动驾驶等功能高额的软件开发成本买单。

• 消费者需求的改变

站在消费者角度，靠传统硬件差异化配置有无，不足以满足差异化需求，需要更多的软件配置来提升使用体验生活，如：个性化界面显示、自动驾驶、智能音视频交互等，普通消费者需要花钱来感受更多的科技体验，等同于现在互联网付费服务。

• 软件定义汽车的功能和性能

智能驾驶、车联网、智能座舱等功能的实现，都主要由于软件来定义，如底层软件Autosar，操作系统QNX、Andriod等，安全软件OTA，还有娱乐化、智能化应用等。

软件决定产品的性能，类似于手机的操作系统，软件的可靠度将直接影响产品的性能。而且汽车还涉及到一些安全层面的功能，黑科技功能不断增加的同时，软件显得更加至关重要。

• 软件缩短功能的迭代周期

传统汽车厂商的销售方式是以销售的实现为终点，“只管生不管养”的模式，依托车型的年改、中改、大改、换代来实现机械硬件更新，迭代周期和成本也很高。消费者对新技术的尝试只能换车，成本相对较高，传统汽车的软件更新几乎与汽车生命周期同步，极大地影响了用户体验。

但特斯拉能够通过硬件升级+软件OTA做到常用常新，软件OTA降成本的同时，大大缩短功能的迭代周期，给消费者带来用户体验的极大提升，其功能付费升级模式也逐渐被传统OEM效仿，国产供应商的产品开发流程和售后维护提供新的思路。目前的传统OEM与特斯拉，有点像诺基亚与苹果的关系，但特斯拉是不是颠覆者还有待时间验证。

目前来看传统的OEM通过软件定义汽车还要一段路程要走，包括电子电气架构、半导体、硬件平台化与预置、自主开发与否等方面。

• 整车电子架构的集中化

受到电子电气架构的制约，传统车企的 OTA 只局限于车载信息娱乐系统等特定功能，假如说一个车有60个ECU，分别由于不同的Tire1开发，有着不同的嵌入式软件和底层代码。这种分布式的架构在整车层面造成了相当大的冗余和BOM成本，而且整车企业并没有权限去维护和更新 ECU。

整车电子电气架构的集中化，使用中央处理器对不同的域处理器和ECU 进行统一管理，可以降低硬件的冗余、BOM成本和OEM对众多Tire1的依赖，模式是自主开发软件还是深度绑定Tire1/软件公司还有待进一步的摸索。

• 半导体算力的提升

整车电子电气架构的集中化，需要半导体算力的满足，如自动驾驶的落地需要一颗小型化、算力强大的计算平台，而不是整个后背箱工控机，如Mobileye的Eye Q4/Q5、英伟达Drive系列、华为的MDC600、特斯拉的FSD，还需要与之配套的运存LPDDR4/5及大容量存储eMMC/UFS/SSD等用于数据的处理和保存。国产OEM厂商可能没有芯片自研能力，可以与供应商合作来满足自身域控制器的研发需求。

• 硬件标准化与算力预置

软件决定产品性能，但是硬件决定产品的天花板，再强大的功能也要依托硬件的实现，软件定义汽车的前提是要做到硬件标准化，进而实现软硬分离。特斯拉提供的硬件升级服务，能从AP2.0/2.5升级为AP3.0，MCU1.0升级为MCU 2.0的服务，硬件的升级对芯片方案、接口平台化，底层软件兼容有较高的要求，要做到硬件的通用性和标准化，为国产供应商的产品开发流程和售后维护提供新的思路。

传统OEM的商业模式不考虑后续的升级需求，在成本压力巨大的竞争模式下，不可能预留芯片算力和存储空间、冗余的模块用于后续的升级，基本上都是刚刚好满足当前功能需求，想要增加功能或者算力，只能更换平台、方案或换件。有些功能可以通过软件优化来实现，但还是受到硬件能力上限的制约。像特斯拉自动驾驶功能的OTA升级，在AP硬件研发的早期就考虑到未来一段时间的软件及AI算力需求，当硬件不足以满足需求时，好的硬件标准化还能通过硬件升级，继续保证功能的实现。

• 自主研发or合作共赢？

传统OEM更擅长的是对传统供应来的管控，对软件的把控能力需要进一步的提高，可能需要绑定一家Tire1合作开发。互联网造车出生就带有互联网的基因，对软件的把控方面可能会更有优势，但对整车产品力的打造和消费者的认可度方面还需要打磨。无论是汽车行业老兵、还是互联网入局新贵，各家有各家的玩法，但最终都要落地到可落地的产品上，需要有消费者为技术买单。

汽车智能化、电子化程度的不断提高，这是大背景，这个大家肯定没异议。毕竟客户爸爸们现在很喜欢，未来会更喜欢。

这时候来了三批工程师要搞定这个事，他们首先要解决的就是咋么把车上这么多电子设备连接起来，这个设计过程就是电子电器架构

所谓「电子电气架构」，简单地说就是把汽车里的传感器、中央处理器、电子电气分配系统、软件硬件通过技术手段整合在一起。通过这种架构，可以将动力总成、驱动信息以及娱乐信息等，转化为实际的电源分配的物理布局、信号网络、数据网络、诊断、容错、能量管理等电子电气解决方案。

通俗来说，汽车是一个软硬件结合的产物，如果把它比作是一个人，「四个轮子+一个沙发」是身体，电子电气架构就相当于神经系统，负责完成各个部位的连接，统领整个身体的运作，实现特定功能。

首先是一群抱着**“机械定义汽车”**思维的传统车企工程师开始动作了。增加电子控制单元(ECU)、增加传感器、增加仪表。要连接了咋么办。哪两个东西之间有需求，就加根线呗。

传统的车上电气系统，大多采用点对点的单一通信方式，相互之间很少有联系

但随着系统变复杂情况不对了，布线系统变得异常庞大, 一辆传统连接的汽车中，导线总长度可以达到2000多米，电气节点可以达到1500多个。导致线束材料成本剧增，可靠性骤减。系统不可持续了。

又来了一群抱着**“硬件定义汽车”**思维的车企工程师开始寻思了，计算机硬件里不是有总线嘛，能不能借鉴下，大家都先连在几根粗线上。

总线技术可以简单理解为高速公路，路上所有的车（信息）都走一段高速，降低道路（线束）成本。

为简化线路连接，提高可靠性、利于各装置之间的数据共享，以汽车分布式控制系统为基础的车载网络总线技术发展起来了。

汽车总线技术的优点是在统一应用层协议和数据定义的基础上，可以使之成为一个“开放式系统”，具有很强的灵活性。对于任何遵循上述协议的供应商所生产的控制单元都可轻易添加入该网络系统中或者从网络系统中拆除，几乎不需要做任何硬件和软件的修改，这完全符合现代汽车平台式设计的理念。因此汽车电子控制采用网络化设计可大大降低设计成本。

当然行人或者自行车（数据）移动的过程对路（线束）的需求不同，不同设备之间的通讯也有不同需求，有些要高可靠，有些要大容量，有些要抗干扰。这也催生了大量的汽车网络如LIN，CAN，CAN FD， FlexRay，MOST，汽车以太网的百家齐放。

表面上，车子都是整车厂造出来的，但这并不意味着车上的所有技术都是由整车厂研发的，供应商才是大部分技术的幕后功臣，而「整合」才是整车厂的重要任务。汽车工业百年发展，早已形成完备且复杂的供应商体系，比如我们常说的一级供应商、二级供应商、三级供应商。。。。

如此多供应商的加持，看起来更牛逼了。旧时代看着是一只军队，新时代里就变成了乌合之众。车企转型需要自身有足够强的研发能力，还得和供应商不断博弈，付出大量的人力物力财力，还需要经过一个比较长的磨合期，才能真正在量产车上落地。

**更重要的，欲练此功，必先自宫，主机厂们担心特斯拉的这种设计趋势会淘汰掉他们数十年来培育起来的零部件供应链。**谁能想到有一天，曾经让主机厂安逸发财的供应链成为阻碍其创新的绊脚石？

大众、丰田、上汽等传统整车厂，体量巨大。在电子电气架构上动刀子 ， 如果不成功，谁来为负责？轻则影响公司未来几年产品的销量，重则事关生死。而且，难免会因此而触犯别人的利益，推行阻力很大。

特斯拉体量小得多，也没什么历史包袱，因此可以直接上手去做。而马斯克个人秉承的第一性原理的思维方式以及超强控制欲，多年以来，公司坚持创新自研、垂直整合，已经是这家公司的深刻烙印。特斯拉在电子电气和软件层面的优势，并不是偶然。

**传统车厂也在行动：**大众开发了自己的 MEB 纯电动平台，同时斥巨资成立软件中心，提升自己的软件能力，与此同时，大众设计了全新的 E3 电子架构，计划将 70 个 ECU 减少到 3 个域控制器。去年 5 月，通用汽车发布了新一代电子电气架构，支持整车 OTA。宝马也在全新一代产品（3 系、X5、X7）都已经可以支持整车 OTA，如果不是在电子架构层面做改变，这个特性是很难实现的。中国的头部 OEM 都在积极开发下一代的电子电气架构，并且在 2022 年左右实现新一代电子电气架构的平台化。

如果你知道整车开发流程，一定知道“冻结”这个概念，关键接口，关键零部件在每个小迭代周期都会进行冻结，以维持各个块线的合作和同步推进，详细可见下面的回答。

许良：汽车是怎么开发出来的？-浅谈汽车开发流程576 赞同 · 62 评论文章

没有OTA或者域控制器之前，智能驾驶功能必须要等到底盘性能完全冻结才能开始进行标定、调教和测试，虽然多数时候会分多个迭代过程，进行多个周期的调试，但不管哪个周期，智能驾驶功能永远是拍在最后的。一旦前面的某些开发出现了延期，在量产前最着急最痛苦的就是智能驾驶工程师，因为压缩的基本都是他们性能提升和测试的时间。

无论生物成长还是汽车制造基本都一个道理：简单构件往往会优先产生并投入工作，以支持复杂构建的产生，骨架，心肺，往往都会优先形成机能并支持大脑器官的发育，后者的成熟周期往往是最长的。不同器官需要处理的任务维度不同，因此复杂度也不同

就像小宝宝，如果它脑袋在出了娘胎后就不成长（传统电气架构），那牛津大学也要在娘胎里读了。虽然骨架，肌肉，心肺都可以在出生前健全，但10个月时间脑子的核心功能是好不了的，他需要对接外部环境。但如果可以后天学习，那ok了，差不多时候我就可以从娘胎里出来了。

OTA或者域控制器的产生，为自动驾驶等功能释放了更多空间和时间，让其开发周期和测试周期得到必要的保障。

把硬件折腾清楚了，充其量就是车的硬件基本可以和一台电脑或者一部手机相比较了，可这些东西可以真正工作起来还缺个操作系统哈（什么android，Windows，Linux），那汽车的操作系统是什么？

请看第二篇

殷玮：软件定义汽车（2）-软件中间件

工程师们把硬件折腾的差不多了，嗯，是不是可以开始应用软件快乐的开发了，还不是哈，我们都知道手机，电脑啥的在应用之下，硬件之上，还有一个东西叫操作系统，车辆里也有类似的东西。

操作系统-我负责对硬件，提供线程创建等服务，其他我不管
中间件-我负责和不同操作系统对接，并给上面应用提供通讯，资源管理等服务，其他我不管
应用软件-嗯，剩下都我的事，我管功能，不同系统，不同硬件的事我不管。

中间件(middleware)是基础软件的一大类，在操作系统、网络和数据库之上，应用软件的下层，总的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。在不同的技术之间共享资源并管理计算资源和网络通信。

另外中间件的定位不是操作系统，而是一套软件框架，虽然包括了RTOS，MCAL，服务通信层等协议和服务。两者看着很接近，但没有多少竞争关系。

操作系统的话题，我们另外一篇文章再聊，今天关注软件定义汽车的话题中心-中间件。

随着汽车应用要求的不断提高，软件总量也随之迅速增长，这导致了系统的复杂性和成本的剧增，为了提高软件的管理性、移植性、裁剪性和质量，需要定义一套架构( Architecture )；方法学( Methodology )和应用接口( Application Interface )。从而实现标准的接口、高质量的无缝集成、高效的开发以及通过新的模型来管理复杂的系统。

目前在汽车控制领域有多种总线标准，各侧重点有所不同。尽管总线通信速度越来越高，但是还没有通信网络可以完全满足未来汽车的所有成本和性能要求，因此需要兼容多种总线和底层协议的通信协议和规范。

中间件的核心思想在于“统一标准、分散实现、集中配置”。统一标准才能给各个厂商提供一个通用的开放的平台；分散实现则要求软件系统层次化、模块化，并且降低应用与平台之间的耦合度；不同模块来自不同的厂商，它们之间存在复杂的相互联系，要想将其整合成一个完善的系统，必须要求将所有模块的配置信息以统一的格式集中管理起来，集中配置生成系统。

这个架构还需要具备如下功能：解决汽车功能的可用性和安全性需求；保持汽车电子系统一定的冗余；可以移植到不同汽车的不同平台上；实现标准的基本系统功能作为汽车供应商的标准软件模块；通过网络共享软件功能；集成多个开发商提供的软件模块；在产品生命期内更好地进行软件维护；更充分地利用硬件平台的处理能力；可实现汽车电子软件的更新和升级等。

所有把标准统一后的服务的优势都大同小异，总结主要几点

• 跨配置，跨车型，跨平台，跨硬件适应
• 提高了效率，软件开发聚焦差异化
• 软件认证有标准可依
• 方便行业软件互换，降低进入门槛
• 更简单的集成已有工具链，支持从设计到代码全流程

对于Autosar，说实话，最有利的是OEM和基础软件公司，OEM可以标准化接口，自己做应用层或找软件公司开发应用，基础软件公司可以多卖软件。最不愿意的是tier1，因为增加了成本，还逐步可能沦为硬件生产商。但这个也不能说是autosar的锅，软件定义汽车下这个趋势的发展是必然的。

老实讲，这块大家讲的很少，都说这个很美好，但实际操作过程中，我觉得是软硬件一体设计上的阻碍。

值得注意的像Tesla这样的新兴企业并没有使用autosar这是为什么？所有平台性的软件，都有一个弊病，就是为了兼容一致性，会对软硬件协作的效率带来影响，autosar也不例外。

我感觉“Autosar就是汽车行业的塞班系统，看似很好，很标准，但是最终会被淘汰。就像当年的诺基亚一样，原因是最后会被一个软硬件集成度更好的iphone取代，iphone可不纠结能够给其他公司用自己的系统。

从商业和成本角度看

Autosar设计上已经有些落后，代码臃肿，对成本影响很大。打个比方，北美一个程序员一年的cost也就是15万美金，自己完成底层的开发就这个价，使用Autosar的工具链和代码臃肿带来的升级MCU开销远大于节省的这部分开发成本。细分Autosar的成本：

1.开发成本:首先需要购买autosar，本身就是成本，autosar包含的模块多，肯定要贵，但不一定所有的都会被用上。其次是人力投入，对于一个原来就有其他平台的新的第一个项目转换到autosar是增加人力的，对于新公司，购买autosar是降低人力的，很多模块不用自己开发了。对于建立平台以后的项目，实际差不多。

2.生产成本:首先是硬件成本，现在MCU越来越便宜，用不用autosar基本没区别，如果说存储空间特别小的MCU，比如防夹模块，本来也没要求autosar。其次是软件成本，这个才是问题，跟以前基础软件不同autosar现在收量产license费。

从技术角度看

关于autosar的应用，autosar之前定义的主要就是BCM、TCU、EMS、ESP等要求实时控制的ECU。不是针对娱乐系统，自动驾驶MPU的，当然这些控制器里也有MCU，可以用运行autosar的MCU。autosar现在最擅长的是16bit MCU以及不