当软件定义汽车成为趋势，未来汽车是否可以理解为四个轮子上的超级计算机？

浅谈汽车软件行业

前几天回答一个问题，讲述汽车行业的写代码的一些习惯，引来了不少争议，因此今天在这儿谈谈软件在汽车行业的现状。

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

确实，以前机械控制的时代，汽车行业确实没有码农一说，不过电控时代好多年了，而且随着电气化，智能化的深入发展，汽车行业对软件工程师的需求也越来越大。

汽车软件属于嵌入式软件开发，跟互联网行业软件开发差别很大。

汽车软件开发特点

一：基于模型的开发MBD

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

1， 图形化设计

汽车软件大部分是基于模型的软件开发。这一点在大公司尤为明显，我们用Simulink将要实现的逻辑用图像的形式表现出来。图形化的设计逻辑明确，清晰，便于交流和维护。对于代码的第一任作者以及以后可能的作者，他们只需要看懂图形，就能知道代码实现了什么功能。而如果不看图，要去重新翻阅成千上百行代码，非常耗时。

图形化的设计

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

2， 代码自动生成

在模型开发里，图像化的算法最后依靠工具来自动生成代码。代码效率明显提高，手工代码耗费时间长，且容易出差错。自动代码只要工具好使，就不会有差错，比手工代码质量高。

二：代码书写标准统一

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

MISRA C Coding Standard是一个工业标准的C编程规范，全称是 (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， 对汽车/受控系统要十分了解。无论是传统车还是自动驾驶系统，都需要对汽车有一定的了解，不然无法开发控制算法。而汽车又是个十分复杂的机械系统，不是临时看看资料就能了解的，因此汽车行业的码农都需要有一定的机械学科背景。

2， 电学知识。汽车软件要接收来自传感器的大量的外部信号输入，包括各种数字信号（开关信号），模拟信号（传感器值），软件工程师有时候需要对这些值进行滤波，计算，转换为自己有意义的输入。因此对于想加入汽车软件行业的初学者也需要一定的电学基础。

3， 需要标定能力。汽车软件很多算法是无法在开发软件的时候得到，需要后期在实车/Labcar上实验得到。所以汽车软件的标定功能是强于其他行业的，汽车软件工程师也需要一定的标定能力来测试和开发软件。

汽车软件行业趋势

1， ECU整合度将提升

早在去年，大众就宣布力争让汽车上只有一个ECU。在一些供应商巨头内部，确实也在这么做。特别是在ADAS和自动驾驶下，整合的ECU架构尤为重要。

2， ECU将承载更多的传感器

未来汽车将需要更多的传感器来感知环境，以及保证依靠传感器来保证冗余设计。这对ECU的能力来说也是考验。不过高级算法与机器学习的发展，有望取代一部分传感器，减少传感器数量。

3， 汽车以太网发展

长期以来，汽车ECU都是在一个封闭的网络环境下。不过随着智能汽车技术，物联网的发展，很有可能会催生汽车以太网，实现跨域通信。不过如何保证功能安全，这将又是对汽车软件的一大考验。

汽车软件的现状和发展方向

本文首发于EE汽车荟，在微信公众号搜索“EE汽车荟”可以查看。

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

简介：本文就目前比较热的“汽车软件”话题，做一些讨论。也试图回答大家比较关心的三个问题。内容主要有三方面：1）传统汽车是否有软件，为什么传统汽车业看起来像是被动地发展汽车软件？2）现在新能源车普遍拥有的语音控制系统，自动泊车，拥堵跟随系统，是否可以认为是革命性的汽车软件？3）汽车软件的前景如何？有哪些瓶颈技术以及创新？

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

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

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

拿比较简单的空调系统来举例说一下。当天气比较热时候，这时候需要把空调的温度调低，比方说，从26度调到22度。我们看下汽车内部是怎么运作的：Step1: 驾驶员手动给空调旋钮一个信号，将温度调整到22度。Step2: 空调控制单元接收到信号后，从车外，出风口等地方收集信息，以决定下一步送风量。Step3: 空调控制单元给予风门控制器一个信号，把风门的角度变大。Step4: 空调控制单元给压缩机一个信号，让压缩机运转，保证后续冷风的供给。完成这个循环后，空调控制单元会重复Step2以决定后续的送风量，风门开启角度。

说明：1）其实Step3和Step4一般是同时进行的，为了简便将其分为两步。2）一般会在空调控制单元本身会附有室内温度传感器，以判定室内温度。这个信号也要传递给空调控制单元。3）手动空调没这么多传感器，主要靠人来感觉温度是否合适，不过其内部有一些经验值参数以及逻辑设定。

我们可以从这个图里面看到，空调控制单元是整个机构的“大脑”，它担负起把人的需求，转化成实际的动作，并检查这些动作是否满足了需求。而这个过程，就是通过软件实现的。其实在空调控制单元里面，有一个小的PCB板，它的上面集成了这些简单的控制程序。可能和我们认识可能有些差异，这个控制器也拥有内存和缓存，并且有处理器。比如德系的空调控制器有大约1MB的内存，用于存储程序（使用C语言编写而成），同时有128Kb的缓存，用来存储临时数据。除此之外，这个控制器内部还有一个处理器，其中一个就是32位的96 MHz的处理器，相对于处理任务来说，这个处理器的速度还是挺快的，原因就是处理器领域摩尔定律太厉害，这已经性价比很高的了。这一点看起来和我们电脑非常的像，只是处理器，存储容量的数量级差太多。这些系统，对互联网思维根深蒂固的现代人来说，就像拿着iPhone的现代人看着Nokia的塞班系统的感觉一样。不过从本质的原理上来说，即使是最传统的汽车，也具备了软件，只是这些软件没那么复杂，看起来还很初级。

如果我们去分析其他汽车的系统，复杂的如自适应巡航系统，甚至自动泊车系统，简单的如玻璃升降系统，灯光系统，我们会发现同样的结果，这些系统中都有所谓的控制器，也有内存，缓存，处理器，程序语言。所有这些共同构成了汽车的各个电控功能模块。只是这些系统独立分布于汽车的各个区域。

简单小结一下几个重要的事实：1）汽车的很多模块都有所谓的“软件”，除了上面举例说明的空调，玻璃升降，天窗等都是这样的小系统。2）这些系统之间很少通信，也就是他们之间不交流。相对而言，这些小而独立的系统，构成了复杂的汽车系统。3）正是由于这些系统的独立性，这些系统没必要协同，也就是说这些系统都是独立开发的。

汽车最复杂的系统就是发动机，发动机控制器叫ECU，号称整车的大脑，其实发动机主要负责行驶相关的事情，其他的系统有一定的简单联络。除此之外的事情它根本不管，从整体上来说，发动机的ECU只是一个比较大的山头而已。传统汽车里面的这些控制系统，以及其内部的软件系统，更像一个松散的组织，跟协会差不多。这和我们熟知的电脑完全不一样，它们都有一个核心的控制系统。与之相比，传统汽车像几十年前的服务器式电脑一样。那么，传统汽车为什么这么久也没有产生这个系统呢？

如果仔细观察传统汽车驾驶情况，就能看出，所有的指令发出，几乎都是人来发出，汽车极少自己做决定，而驾驶员在里面充当了我们电脑CPU的作用，由人来协调各个控制系统的运作，甚至反馈运作的好坏并修正。在传统汽车时代，驾驶员在车内，除了听听收音机，享受下空调，几乎没有任何娱乐活动，他主要的活动就是加油，刹车，看后视镜，转向，和现在的出租车驾驶员差不多。而各个系统不相互交互其实提升了可靠性和安全性。所以，从驱动力量上来说，汽车完全没有必要去发展架构更好的软件。现在伴随着娱乐活动的增多，在车里的无聊驾驶时间就显得弥足珍贵了，也是各大商业机构来争抢的蛋糕。所以大家都在研究怎么把驾驶时间给解放出来，把商业或者娱乐应用加进去。从这个角度说，汽车自身是无法进化出所谓的中央系统的，这个中央系统是外界所迫，而不是汽车的核心需求。

二．现在很多智能汽车的软件是革命性的吗？

在这几年的新能源汽车发展，催生了很多“智能”系统，比如语音控制系统，自动泊车系统，拥堵辅助系统。这些系统仿佛是新能源汽车的标配，好像有了这个系统一下子汽车变成了新物种，就是智能汽车了。为了和传统汽车划清界限，这些汽车连宣传卖点都变了。

下面我举语音交互系统的例子来分析一下其运作过程。Step1：语音交互系统待机，普通的启动方式一般是“小X，小X”。Step2: 驾驶者发出一条指令，为了方便期间，我们还拿空调做例子，比方说把空调调节到22度。Step3：麦克风接收指令，将指令转化为可以执行的命令，并将此命令发送给空调控制器。Step4：空调控制器发送指令给风门……我想后面的命令大家都很熟悉了，这个和传统车一模一样啊。Step5: 空调控制器指令发出后，反馈给驾驶员信息，表示已经开始执行命令。这里面最复杂是Step2，就是麦克风如何把语言转化为命令，我们简要分析下。

语音输入如何转化为命令，这和我们手机的语音识别比较类似。这里面涉及到一个语音库的内容，即在语音识别前，将常用的语音录进去，形成一个清单，一旦输入的语音和清单中相符，即启动清单相应的命令。随着语音能控制的范围增大，这个语音库也会不停扩充。目前市面上的语音识别，甚至和驾驶员能够做简单的聊天，这和聊天机器人挺像，不过这已经不是汽车控制领域内的事情了。

从简图中可以看到在语音转化为命令过程中，产生了一个所谓的输入，输出，反馈系统，这就再次形成了一个汽车内部系统。因此在车机里面，集成了语音识别软件，当然也有所谓的内存，缓存，处理器等。只是车机的处理任务，相比我们传统汽车的空调控制器来说，要复杂很多，语音除了可以控制空调，也能控制整车的娱乐系统，天窗和车门玻璃的开合。

目前应用比较广泛的智能系统，我们会发现这些都是偏信息娱乐类的，也叫汽车舒适域。一旦涉及到整车的动力/驾驶，就只有很少的车企涉猎，并建立控制系统。现在所说的智能系统，很多都是从传统车本身就有的自适应巡航，自动泊车改造而来。所以，可以这么理解，现阶段大部分所谓的智能汽车，实现比较多的是把手机搬到了车机的显示屏上，这样整车可以显示更多的信息，实现车主的娱乐需求，完成一些简单的车辆控制。而汽车的核心–驾驶系统，目前还独立在智能之外。只有自适应巡航，自动泊车这些所谓的智能软件的发展，才算触及到了汽车功能的底层，而真正的自动驾驶，才可以称作用软件重新定义了汽车。

在传统车的网络架构里面，舒适域和行驶域是通过网关隔开的，也就是说舒适域无法去指挥行驶系统，只能通过我们的肢体动作来影响车辆行驶。也就说，一个车怎么“娱乐”都不会影响到整车的驾驶。为了方便理解整车娱乐和整车行驶系统的区别，我们举例说明下自适应巡航系统的过程：Step1：汽车得到自适应巡航的指令；Step2：采集雷达信号；Step3：采集ESP和转速信号；Step4：根据采集到的参数计算，调节喷油量；Step5: 调节变速箱档位；Step6: 调节制动压力。这里面Step2/3基本是同步完成的，Step4/5/6也是基本同步完成。从这个系统中，我们看到软件系统，开始介入到整车最核心的底层，也就是发动机/制动机构的操作。我们可以说，这才是真正的汽车软件。这个系统的计算量，对安全性的要求，和娱乐系统相比，都要高出一大截。而且这个系统的“大脑”是整车最重要的ECU，它亲自指挥了这个系统，在重要性上，传统车的ECU高于一切，这就是整车运作的基础骨架。

小结一下现在汽车软件的情况：目前大部分软件已经基本进入了整车娱乐系统以及简单的控制系统，不过只有很少车企才开始涉及整车的核心–驾驶系统。汽车软件还不能说是革命性的，只是比以前有很大进步。

三．未来汽车软件发展的方向和瓶颈是什么？

未来的汽车软件会发展成什么样子呢？习惯互联网思维的人总是说，快鱼吃慢鱼，迭代。而这些似乎和汽车无关，汽车的软件仍然是肉眼不可见的蜗牛式的慢速发展。这里面到底有什么原因呢？是互联网行业颠覆不了汽车业，还是汽车业太保守？汽车原本是机械控制的机器，在汽车界少有码农说法。只是汽车有越来越多的电器，也有越来越多的所谓智能功能，汽车软件才被提出来。

先来分析下传统汽车软件和互联网软件的区别。传统汽车是功能优先，比如我们说的空调系统，要实现制冷，制热的功能，而里面的软件只是为了方便硬件之间的协同，才被开发出来，这叫嵌入式软件开发，也是传统汽车里面绝大部分系统的开发方式。伴随着汽车供应商的发展，各个汽车系统都有强有力的供应商把持。所以这个软件开发核心考虑的功能满足，至于是否节约精简，和其他软件如何协同，这就不是重要的因素了。所以这时汽车软件和互联网行业软件开发的第一个区别，出发点和平台不同。

从汽车的发展来说，汽车软件都是从嵌入式软件发展起来，可以说汽车行业是传统行业，也是比较慢的行业，完全不能和互联网相对比。为什么汽车软件无法实现快速的迭代升级，只能按部的开发。其主要原因在于汽车非常强调安全性，这里面包括各种我们默认的问题：1）软件是否会出错，如果出错，后果是什么，如何避免出错？2）软件出错，如何修正？3）如何追踪出错的软件？所以汽车软件的开发，不太可能有革命性的发展，永远是步步为营，因为安全永远是在第一位的。在传统汽车软件里面，我们可以看到很多的额外安全设定，就是为了避免意外。我们的手机软件出错了，最多死机，很快后台就会有程序更新，把Bug修复。而汽车的软件，尤其是驾驶相关，是不允许出错的，特别是行驶当中。因为一旦有了问题马上就出出现以下结果：造成人员伤亡，这是无法允许发生的。而后面的问题对主机厂也是一个难以面对的局面：责任判定，车辆维修和召回，不但有大量的经济损失，也会引起大量的社会恐慌。所以汽车软件还有功能安全来进行冗余设计，避免特殊情况下带来的危害，也就是说要保证汽车始终可控。这就是汽车软件与互联网软件的第二个区别：汽车的安全属性太强，以至于软件开发的原则，是安全性，而不是便利性。

不过伴随着四化的进展，汽车软件无疑受到了最大的冲击。在此背景下，汽车软件也发生了很大变化。我想汽车软件行业如果想变化，学习现有的互联网即可。在这里首先要解决两个技术瓶颈。

首先要有的就是，汽车软件编写要有自己的规则，如MISRA，这就是目前汽车界为了统一大家的编写语言架构制定的规范，考虑到汽车软件的复杂度，这个规范和互联网编程规范比起来，非常的简单幼稚。而我们熟知的手机APP的开发，目前主流的已经跟PC的软件开发框架融合的很好了，手机的操作系统主流的就是IOS和Android，还有winCE，这些操作系统发展的很成熟，开发框架已经逐渐和原有的PC这些主流编译和开发语言整合了，比如JAVA的体系已经把基础库都涵盖了不同操作系统的编译能力。

其次，汽车界有可能诞生新的编程架构和规范吗？这就是AUTOSAR(AUTOmotive Open System Architecture 汽车开放系统架构)。这是一家致力于制定汽车电子软件标准的联盟，由全球汽车制造商、部件供应商及其他电子、半导体和软件系统公司联合建立，各成员保持开发合作伙伴关系。自2003年开始，AUTOSAR架构致力于车辆电子系统软件的交换与更新，并为高效管理愈来愈复杂的车辆电子、软件系统提供了一个基础。这个规范，其实就是实现了现在互联网界的几个基础：软硬件分离，各软件之间使用统一语言交互，各种接口统一，便于通信。不过这个架构虽然公布了十多年了，不过鲜有革命性的成果，我估计是因为各个汽车厂都有自己的小算盘，大家都在憋大招，不想轻易把一些东西让出去，就像每个传统制造企业都想保护自己专利一样。所以，各个主机厂也在出自己的标准，也有很多供应商参与到这个工作中来。

解决了这两个基础问题，那么汽车行业的软件会向哪个方向发展呢？最重要的就是像互联网一样的整体架构，也就是架构设计。

个人觉得汽车的智能化属性越来越强，加上摩尔定律在硬件行业的持续作用。从长远来看，汽车软件必将面临整合。分布于汽车各个区域的分散的软件，将来会集中到某一个或几个ECU中，也就是软件层面上，汽车具备了“大脑”。另外，随着各种传感器，雷达的价格降低，性能提升，这些ECU会接管更多的传感器，并收集这些信息进行计算。除了汽车本身的软硬件发展，其相关的网络发展，如5G，车内网的发展会助力车内电器以及软件的互联，也就是说，软件的连接有更多的介质，而不是总依靠于信号线。

在这里我们可以参考下Tesla Model 3的电器架构来看新的的汽车软件发展。

相比于现在传统汽车分散的控制器以及软件，Tesla有三个核心的“处理单元”：自动驾驶和娱乐模块，左侧车身控制器，右侧车身控制器。第一个模块负责驾驶辅助/娱乐系统，也可以说这个系统可以深入到汽车控制的底层。后两个分管了汽车的车门，灯光，底盘系统。其实这个架构非常像电脑的架构，电脑有所谓的南桥北桥，也有CPU，在电脑上各个硬件的交互非常成熟，也非常流畅，有业内人士指出Tesla车身电器架构的设计之初就是借鉴了电脑的架构，所以从这个角度来说，Tesla的整车，更像行走的电脑。相比于现在其他主机厂的汽车，还是在汽车上增加电器的模式，如果Tesla的道路证明是成功的，那么现在来看，Tesla对于目前市面上的车来说，是一个革命性的存在。

除此之外，Tesla还有自己的电池管理系统，热管理系统，能源分配系统等，这里不是我们讨论的重点，就不再累述。除了以上架构的不同，Tesla在内部也启用了车内网。从实际的使用体验来看，Tesla有更多的人车交互，这带来的更多的乐趣。所以很多人评论说，Tesla更像一个Computer，而其他的汽车更像Machine。

从上面Tesla的例子来说，它至少实现了我们所说的几个未来趋势：软件整合，车内网以及更多的传感器的接管（在某些功能上Tesla其实不算传感器最多的，其他新能源车如小鹏有更多的传感器）。在可见的商业领域，Tesla可能代表了未来的趋势。从瓶颈上来说，还有三个技术难点：1）传感器，特别是激光雷达的技术革新和价格降低2）各种软件的进一步道路试验，已进行安全性的改进，如自动驾驶还需要更长里程的实验，以及各种场景的实验。3）如何用用更稳定的车内网来替代现有的信号线，以带来更大的硬件和软件空间。

从可见的将来来看，整车的智能化，会更快的上来，只是没有互联网所说的那些“迭代”那么快而已。第1点和3点，对业界来说都一样，大家的起点一致，也受限于几家硬件供应商。第2点，各个主机厂的准备情况和道路也都不一样，有Tesla的自己设计验证，也有大众投入巨大的MEB+VW.OS，通用的Cruise，谷歌的Waymo。有长于创新，制造出颠覆性产品的参与者；也有长于安全，制造出可靠产品的参与者；还有完全的非汽车行业的跨界者。最终的胜出，我想不是一个选择题，而是一个整合题。

---

泻药，回答这个问题我们首先要理解什么是“软件定义汽车”，为什么这个事有必要，并深入了解什么最终决定了"软定车”的成败。文章略长，由浅入深，可放心食用。

如何理解「软件定义汽车」？

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

传统汽车到底出现了什么问题？

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

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

软件定义汽车，说直白点，就是把车做成手机

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

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

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

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

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

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

软件定义汽车，虽然名字有软件，最先开刀的还是硬件，手机已经是一个满足软件定义的硬件系统了，除了一些基带芯片等专用芯片，大部分功能需要都集中在一个芯片里，而汽车完全不是，大大小小一堆，改变也不是一个纯粹技术问题，可以看我在专栏中的专题文章

---

---

这里提纲挈领的把核心观点总结下。**首先我们要看到传统汽车到底出现了什么问题？**假设你有一个手机，打个游戏每个颜，安装更新，一般几分钟里面就完成了。 但如果是一个汽车，你希望更新一个功能，从被甲方知道到实现，至少需要2年的时间。过去还好，但在新时代客户已经很难容忍这种开发周期，我们希望汽车的功能迭代能够像手机一样的方便。

因此，软件定义汽车，简单说，实际上就是想把汽车做成手机或者计算机的样子，我这里花了个草图比对下两者的差别

传统车辆电气结构就是以CAN网关为中心的多个独立小控制器，车厂的工作简单来说就是定义好要什么功能，供应商给个小控制器（VCU）实现，然后供应商告诉车厂，我的控制器要正常工作，需要什么信号进，要什么信号出，车厂把他设计到整车DBC中，形成一种CAN上大家互传信息的公共协议。所有功能基本就可以RUN起来。

然而当客户的更新需求越来越快的时候这个方法就不靠谱了。

如果客户要增加一个功能。控制器A要变化->CAN协议和链路要发生变化->用到这个协议的其他控制器也要变化->如果这个功能要增加一个新的控制器，则整个线束连接都要发生变化。然后供应商A，供应商B，供应商C排着队问车企要变更费用，要开发周期（半年-1年）更遭罪的，这种变更哪怕要更新软件，也要去4S店，或者压根不可能，下一次变更需要再等1年。这些零零散散的控制器相互耦合，导致了车辆无法快速的进行功能迭代。

而反观手机就没有这种问题，原因就是整个手机只拥有一套芯片，一套控制器，一套操作系统，软件在这个基础上的任意更改变得容易很多，并且不需要对硬件作出什么变更。再次说明了，软件定义汽车就是要让汽车变成手机，变成计算机，可以安装自己喜欢的软件，可以随时更新软件版本，便捷快速，即安即用。就如同题主说的，未来的智能汽车如果给你的感觉，是在一台“超级计算机”上安了四个轮子，那他就成功了。因为一个计算机就可以很好的更新功能。

总结下，**为什么会要做软件定义汽车？**因为需要解决客户爸爸日益增加的功能需求和缓慢的整车开发流程之间的矛盾。**软件定义汽车做了什么？，**让整个系统在硬件上拥有更高的集中度，在软件上拥有更广泛的灵活性。技术细节我写了四篇文章，需要专业分析的可以看下

---

---

1、为什么软件定义汽车？

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

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

• OEM研发模式的优化

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

• 消费者需求的改变

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

2、软件如何定义汽车？

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

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

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

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

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

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

3、怎么实现软件定义汽车？

目前来看传统的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合作开发。互联网造车出生就带有互联网的基因，对软件的把控方面可能会更有优势，但对整车产品力的打造和消费者的认可度方面还需要打磨。无论是汽车行业老兵、还是互联网入局新贵，各家有各家的玩法，但最终都要落地到可落地的产品上，需要有消费者为技术买单。

---

软件定义汽车（1）-整车电子电气架构EEA

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

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

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

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

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

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

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

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

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

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

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

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

综合考虑功能和位传输速率等因素现有的汽车通信网络大致可划分为ABCDE类网络：
A类网络主要应用于低速场合，通信速率不超过10kb/s。目前A类网络中应用最广的是LIN总线。LIN总线标准是由LIN协会制定的专门用于低速网络的低成本网络解决方案。
B类网络主要应用于实时性要求不高的场合，通信速率一般为过10~125kb/s。以前有低速CAN，J1850和VAN等多种，目前低速CAN总线成为B类网络中的主流。
C类网络主要应用于实时性要求较高的场合，通信速率一般为125~1000kb/s。目前C类网络中主要有高速CAN，FlexRay其中仍属高速CAN使用较为广泛，普遍应用于动力、底盘、发动机等领域的控制。
D类网络主要面向多媒体、导航系统等领域，网络的数据传输速率为250kb/s~400Mb/s。目前的D类网络总线有IDB-1394和MOST。两者目前在量产中是并存关系。
E类网络主要面向成员的安全系统以及车辆被动安全领域。目前主要的E类网络主流为Byteflight，其最高传输速率10Mb/s。特点是强调高安全性。

可问题又来了，这高速公路是修了，成本也节省了，可这道路上的交规（总线协议）是几个山头（ECU供应商)定出来的，不允许你变化。最多两年变一次（整车开发周期）。还有一种情况是本来走自行车的现在要走卡车了，这路面又支持不了了，部分总线比如LIN,CAN并没有很高的容量扩展性。需求变化了，基本就只能让客户爸爸等两年换一辆车了。

这个时候抱着**“软件定义汽车”**思维的工程师跨步走来，看着他们好像要做软件了，实际他们第一件事还是尽可能的要折腾下硬件，就是在把尽可能多不同的总线合并（所有路都按照一个标准修建），另外尽可能多的合并控制器（哪有那么多山头，交通部全中国就一个），这样后面有个啥世博会，马拉松啥的，我可以根据需求统一变化，适应各种需求。

博世电子电器架构研究研究

这里还是要再专业点描述这个问题，在软件定义汽车思维下有三个重要的关注点

**硬件成本进一步降低：**相同功能需求下，减少 ECU（电子控制单元）数量，可以降低 ECU 物料成本，另一方面也进一步减少了整车线束使用量。Model S 线束约 3 公里长，而 Model 3 缩短了近 1 倍。

**硬件抽象：**此前的供应体系是供应商将「软件+零部件」打包卖给主机厂，软硬件的耦合很深，议价能力差，测试调试苦难。特斯拉的牛叉在于软件基本自己写，即便更换硬件供应商，也不会显著影响软件功能的部署。

**OTA升级：**在硬件抽象的基础上，特斯拉可以通过 OTA 的方式进行新功能的更新下放，以及对车辆状况进行良好监控，降低维修成本。整车软件开发变得更多样化，更简单。

一个最经典例子：特斯拉通过 OTA 解决制动距离过长的问题。彼时 Consumer Reports（消费者报告）发布的特斯拉 Model 3 测评中指出，这台车的 60mph-0 刹停距离并不理想，达到了 46.33 米，但是经过 OTA，Model 3 的刹车距离得到了显著提升。

刚才说了有三批工程师来解决这些问题，目前第二批工程师代表了主流的主机厂，而第三批工程师代表了Tesla等新兴的车企。主流主机厂看Tesla不眼馋嘛？家大业大干不过他？还真是。。。

阻碍帝国成长的是帝国本身，软件定义汽车本质就不是一个技术问题

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

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

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

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

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

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

趣闻：量产过程，不是自动驾驶工程师不努力，而是臣妾做不到哈

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

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

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

自动驾驶的研发周期理论上就不可能和整车研发周期契合！

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

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

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

你以为结束了？软件定义汽车的工程师刚刚完成了第一步!

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

请看第二篇

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

软件定义汽车（2）-软件中间件（Autosar为例）

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

操作系统，中间件，应用软件-各司其职分工不同

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

中间件(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以及不太复杂的32bitMCU。32bit以上的MCU，需要RTOS支持，比如自动驾驶软件。 车的中控也不可能基于autosar,也是因为没有一个强有力的RTOS， 在越来越强调security的软件开发中，AUTOSAR也没有进程隔离的概念。前景难料.

中间件的明星方案-AUTOSAR

所有中间件方案中，最著名的是AUTOSAR, 其是由各大整车厂商和零部件厂商开始着手联合制定软件的标准化接口。AUTOSAR(AUTomotive Open System ARchitecture)是由全球的主要汽车生产厂商、零部件供应商、软硬件和电子工业等企业(如BMW、BOSCH、Continental、DAIMLER、Ford、OPEL、PSA、TOYOTA、VW等)共同制定的汽车开放式系统架构标准。

2003年7月，由宝马、博世、大陆、戴姆勒-克莱斯勒、西门子VDO和大众联合成立AUTOSAR发展联盟，为汽车E/E架构建立了一种开放式的行业标准。

2003年11月，福特公司作为核心伙伴加入，12月标致雪铁龙和丰田汽车加入。接下来的11月通用汽车也作为核心伙伴加入。自从西门子VDO被大陆在2008年2月收购后，它就不再作为AUTOSAR的独立核心伙伴。

• 第一阶段（2004-2006）：标准基本开发时期（版本1.0.2.0和2.1）
• 第二阶段（2007-2009）：体系和方法相关方面扩展（版本3.0，3.1和4.0）
• 第三阶段（2010-2013）：可维护性和可选择性的改进（版本3.2，4.1和4.2）

在2013年，AUTOSAR联盟进入一种持续改进模式，主要用来维持标准和提供所选择的改进,往后实际上，autosar更新就很少了，开始转向AUTOSAR-Adaptive。

AUTOSAR-Adaptive拯救AUTOSAR

对于用于实现典型动力总成和底盘功能的深度嵌入式系统，AUTOSAR经典平台仍将是首选。在低成本硬件上运行时，对安全性、实时性和确定性要求较高。同时，AUTOSAR为这些应用程序提供了一个经过良好验证的成熟软件平台，包括一个广泛使用的方法，它支持当今所有的协作模型。而为了支持客户应用程序的动态部署，并为需要高端计算能力的应用程序提供环境，AUTOSAR在2017年推出了第二个软件平台，即AUTOSAR Adaptive platform。这个想法是尽可能从其他领域(如消费电子产品)的发展中获益，同时仍然考虑汽车的特定要求，如功能安全。

Adaptive需要支持，未来E/E架构的两个关键特征是：

**1) 异构软件平台的集成，**当今汽车的网络架构可以聚集成不同的领域，用于信息娱乐和连接、底盘、动力系统等。虽然infotainment ECUs通常使用Linux、QNX或其他通用操作系统，但AUTOSAR Classic平台是深度嵌入式控制单元的标准。随着新的用例和对计算能力的深入嵌入式应用程序不断增长的需求，第三种ecu将出现，它具有不同的特性，必须集成到现有的E/E体系结构中。

2) 面向服务和基于信号的通信，传统的汽车通信仍然是基于ecu向其他ecu提供信号广播的思想。这种范式非常适合于有限大小的控制数据，这些数据必须循环地进行通信。先进的应用程序，如高自动化驾驶与更高的负载要求，例如交换对象列表检测到的一组传感器和以太网作为一个通信系统需要更复杂的协议。面向服务通信的概念是基于在通信系统上提供服务的应用程序和订阅此服务的其他应用程序。然后数据只发送给订阅服务器。

面向服务的通信与现有的基于信号的范式的结合是未来E/E体系结构的第二个关键方面，从这个角度来看，这是一个艰巨的挑战。

为了解决AUTOSAR僵化的问题，Adaptive希望可以找到一种中间过程平台

ADAPTIVE为承载这些功能的软件基础设施增加了新的需求。除了现有的需求(如功能安全和安全性)，软件架构还必须支持硬件(如具有高端计算能力的硬件)、空中更新、与后端系统的通信或应用程序的动态部署。

AUTOSAR Adaptive扩展了AUTOSAR平台，以满足当前汽车自动驾驶、电气化和互联互通等趋势的需求。因此，它在许多方面改变了已建立的E/E开发过程。最重要的变化是，基于信号的通信被面向服务的设计所取代。c++取代了C语言作为自适应应用程序的编程语言，以及基于posix的操作系统(如Linux用于自适应电子控制单元)是进一步的突破性转变。

AUTOSAR Adaptive 组件封装了SOA软件底层的通讯细节(包括SOME/IP协议，IPC等)，同时提供代理(Proxy)-骨架(Skeleton)模型，该模型以C 面向对象语言描述，方便上层应用开发人员调用标准服务接口(API)进行开发。Application Design Model是该模型另一种可配置的呈现，开发人员通过使用相应的配置工具对Application Design Model进行描述和配置，即可实现基于SOA服务架构的软件落地和部署。联合电子使用AUTOSAR Adaptive组件完成SOA服务架构软件的开发

可以看到，自适应Autosar又找到了延续自己生命的另外一个理由，提供了一种由现在信号导向的架构往SOA架构的标准。未来由于控制器数量大幅度降低, 类似特斯拉这样的车企多半是不理会自适应AutosarAdaptive

与此同时，更多的相关配套供应商也在加快与AUTOSAR自适应平台的对接。去年11月，Real-Time Innovations（RTI）宣布，AUTOSAR最新版本的自适应平台（版本18-10），已经具有数据分发服务(DDS)标准的完整网络绑定。这意味着汽车制造商现在可以使用DDS实现AUTOSAR自适应框架，并开发高度自动驾驶系统，如4级和5级。DDS允许AUTOSAR完全支持高度自动驾驶系统，并提供“量产级通信框架”，保证这些复杂系统所需的可靠性、可伸缩性和性能。比如，在AUTOSAR中完全指定了DDS之后，汽车行业现在可以使用RTI Connext和DDS开发高性能应用程序，比如传感器融合应用程序。

AUTOSAR版本18-10有助于解决OEM软件开发团队在支持不同价格区间车型时所面临的各种安全和连接性挑战。此外，允许开发人员“动态配置平台”，以支持每个车型平台的各种操作模式和硬件功能。

软件定义汽车过程中 中间件就讲到这里，以下是技术细节，可看可不看。可转战下一个内容

技术细节-AUTOSAR的分层设计

这一块是非常技术的部分了，如果不是非常想学就可以跳过了，讨论autosar的分层设计要从如下几个角度切入。架构，方法学，应用接口。详细了解的话可以看这个文件

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rDmSgpXx-1657816559642)(https://zhstatic.zhihu.com/assets/zhihu-components/file-icon/zhimg_answer_editor_file_pdf.svg)]AUTOSAR-EXP-LayeredSoftwareArchitecture.pdf1.1M·百度网盘

架构层面： AUTOSAR定义一个软件分层架构以支持汽车电子系统的集成。其体系架构从上至下依次为应用层、运行环境层(RTE)、以及基础软件层（BSW)

接着再复杂一些，BSW再分为复杂驱动模块， 微控制器抽象层、ECU抽象层、系统服务层

(1)应用层。包括应用软件组件、传感器和执行器软件组件，都位于应用层。该层的软件组件通过RTE进行内部通讯和访问ECU资源。应用层的软件实现独立于微控制器、ECU。

(2)RTE层。RTE层为应用层提供通讯服务。RTE层的实现与ECU和具体应用相关，必须为每个ECU分别实现，AUTOSAR软件组件之间通信需要通过RTE。

(3)服务层。包含RTOS、通信与网络管理、内存管理、诊断服务、状态管理、程序监控等服务。它为应用和基础软件模块提供基本服务，包括：操作系统服务、汽车网络通讯和管理服务、存储服务、诊断服务和ECU状态管理。服务层的实现部分与微控制器、ECU和具体应用相关。

(4)ECU抽象层。ECU抽象层抽象出ECU结构，如外设与ECU的联接方式等．虽然该层与ECU平台相关，但是与微控制器是无关的。这种无关性是由微控制器抽象层来实现的。其中封装了微控制器层及外围设备的驱动，并对微控制器内外设的访问进行了统一，实现了软件应用层与硬件系统的分离

(5)微控制器的抽象层(microcontroller abstraction layer，MCAL)。位于基础软件的最底层，包含了访问微控制器的驱动（如I/O驱动、ADC驱动等），做到了上层软件与微控制器的分离，以便应用的后续的移植复用。微控制器的抽象层是实现不同硬件接口统一化的特殊层，通过微控制器的抽象层可将硬件封装起来，避免了高层软件直接与微控制器的寄存器打交道。MCAL提供消息机制，并以此将指令、响应和信息分离成不同的过程。微控制器抽象层包括微控制器相关的驱动，它负责管理微控制器的外部设备，并将微控制器的信号提供给基础软件的元件。

(6)复杂驱动层，由于其严格的时序为应用层通过RTE访问硬件提供支持。

再复杂一些

再再复杂一些

-------------接着我们从RTE层往上看-------------

运行时环境( RTE )是应用软件和基础软件通信的桥梁，无论通信发生在 ECU之间( 如通过CAN、LIN、FlexRay、MOST等网络) ，还是在ECU内部，RTE均通过提供一致的接口和服务来实现SWC之间的通信抽象，其最终实现会因ECU的不同而有所差异。一般情况下，每一层只能使用下一层的接口，并向上一层提供服务接口。

应用层中的功能由**各软件组件（SWC）**实现，组件中封装了部分或者全部汽车电子功能，包括对其具体功能的实现以及对应描述，如控制大灯，空调等部件的运作，但与汽车硬件系统没有连接。

在设计开发阶段中，软件组件通信层面引入了一个新的概念，虚拟功能总线VFB（Virtual Functional Bus），它是对AUTOSAR所有通信机制的抽象，利用VFB，开发工程师将软件组件的通信细节抽象，只需要通过AUTOSAR所定义的接口进行描述，即能够实现软件组件与其他组件以及硬件之间的通信，甚至ECU内部或者是与其他ECU之间的数据传输。

因此软件组件只需向VFB发送输出信号，VFB将信息传输给目标组建的输入端口，这样的方式使得在硬件定义之前，即可完成功能软件的验证，而不需要依赖于传统的硬件系统。

中间件RTE与**面向对象OO（object oriented）**的编程思想非常接近，所有ECU所对应的RTE都是特定的，它负责着软件构件间以及软件构件与基础软件之间的通信。对于软件构件来说，基础软件不能够直接访问，必须通过RTE进入。因而RTE也被理解成是VFB的接口实现。

而构件之间及构件与基础软件的通信关系如图所示：

AUTOSAR软件构件无法直接访问基础软件中的操作系统OS，因而在应用程序中就不存在「task」的概念，且不能动态创建线程，因此并行的任务由RTE直接管理调入的「构件运行实体」来实现。每个软件构件也许会有一个或者多个运行实体，但是一个运行实体只对应一个入口。

方法学层面

「AUTOSAR方法论」是指在汽车电子系统开发的某些步骤中所需要的通用技术方法。

1、 但AUTOSAR方法既非完整的过程描述也不是商业模式，也没有定义「角色」和「责任」。

2、 方法论仅是一个work-product flow，并定义了其中的依赖关系。

根据AUTOSAR方法论，完整的基于AUTOSAR规范的配置生成过程分为以上图示两部分，即系统配置过程及ECU配置过程。两者之间并无先后关系，系统配置过程中的输入包内含有ECU配置的相关模块，ECU配置也会反馈于系统配置。

系统配置过程：

系统配置输入（System Configuration Input）必须被定义好，AUTOSAR倾向于通过信息交换格式（软件构件、ECU资源、系统限制）以及模版来减少这些厨师系统设计决定的正式描述。模板包含三部分：

• 软件构件的描述：定义每个需要的软件构件的接口内容，如数据类型、端口、接口等
• 系统约束描述：如总线信号的定义、拓扑结构与软件构件之间的映射关系
• ECU资源描述：定义每个ECU的资源需求，如处理器、外部设备、存储器、传感器以及执行器

配置步骤如下

输入的系统配置文件借助配置系统（configure-system）将软件构件映射到资源与计时要求相关的ECU上，所得到的文件就是系统配置描述文件（system configuration description）。其中包含了软件构件与ECU映射时所需注意的限制条件，以及通信矩阵（Communication-Matrix），矩阵中描述了整车网络结构中的数据包内容及其时序关系。

ECU配置过程

系统配置完成后，生成了系统配置描述文件，作为ECU配置过程的输入。

Extract ECU-Specific Information会负责从系统配置文件中剥离出各ECU相关的系统配置信息，如通信矩阵、拓扑结构、顶级功能组合，生成到ECU Extract of System Configuration中。

Configure ECU的是生成包含了特定ECU局部信息的ECU Configuration Description，而这些信息可以构件该特定ECU的可执行软件。

Generate Executable根据从ECU Configuration Description中得到的信息生成可执行程序。

AUTOSAR 的特性使得当ECU底层硬件配置升级时，也并不一定要牵动其他软件系统，正因其统一的标准规范，越来越多的企业将会加入到其中，这也为未来汽车电子行业内高效管理以及复用愈加复杂的汽车软件系统奠定了基础。

• AUTOSAR 中SWC(Software Component Description)包含下列信息: 该SWC用到或被用到的Operation和Data，SWC对基础构架(网络)和对硬件(延迟时间，定时等)的要求，SWC使用的资源 (存储器, CPU时间等)，运行机制(重复率)，SWC软件接口。
• AUTOSAR中ECU Resource Description包含下列信息:描述使用到的硬件:传感器，执行器，存储器，处理器，通信外部设备（如收发器），引脚分配。
• AUTOSAR中System Constraint Description中包含下列信息:网络拓扑，限制，协议，通信矩阵，波特率，定时，ECU映射。

系统配置主要是将端口数据映射到通信矩阵，将SWC映射到ECU。ECU配置主要是将runnable(可运行实体)映射到task(任务)中。对以上各项内容角色分工

接口层面：

AUTOSAR各层软件的交互通过三类接口实现，分别是标准接口、AUTOSAR接口和AUTOSAR标准接口。其中，标准接口用于BSW各个模块之间的交互，已用C语言定义，如void Adc_Init (const Adc_ConfigType* ConfigPtr)。AUTOSAR接口用于软件构件（Software Component, SW-C）之间的交互或者软件构件和ECU硬件（IO硬件抽象、复杂设备驱动）之间的交互，这类接口命名以“Rte_”为前缀。AUTOSAR标准接口用于软件构件访问AUTOSAR服务。

依赖这种分层架构和接口定义，AUTOSR显著提高了汽车电子嵌入式软件的复用性——层级越高者，复用性越强。值得注意的是：

• ·微控制器抽象层层级最低，随微控制器的更换而更换；
• ·RTE虽然层级仅低于应用层，但由于它承担着应用层和BSW之间的桥梁作用，和硬件的耦合性最高，不具有复用性；
• 应用层(除传感器、执行器相关的软件构件外)完全独立于硬件，具有绝对的复用性。

AUTOSAR在定义软件架构和接口的同时。也定义了易于交换的硬件平台标准。AUTOSAR标准不仅提供了基础软件模块的规范。还提供了用于开发分布式系统应用软件的方法。这种方法以基于模型的软件和分布式系统描述开始。以自动代码生成和可重复的测试结束。

Autosar也定义了与网络总线接口相关的模块，CAN,LIN等网络总线接口驱动、诊断等。AUTOSAR的出现使得ECU中的软件包括网络总线通信软件第三方供货成为可能。未来的网络总线标准是否仍然各自独立、互不兼容，目前还无法断定，但AUTOSAR却实实在在地将部分标准公开化、标准化，兼容化，而且实际的产品也已经被应用，AUTOSAR已对现在相互之间封闭的网络总线标准形成挑战。

此外，AUTOSAR还定义了一套标准的软件开发流程，从系统建模到生成可执行的代码，包括软件组件设计、系统配置、ECU配置和代码生成三大流程，如图

技术细节-AUTOSAR ADAPTIVE架构介绍

软件定义汽车（3）-SOA架构

好了，硬件折腾过了，中间件也有了，是不是就可以愉快的应用开发了，不，还有一个共享的思想必须掌握，接上一篇文章

殷玮：软件定义汽车（2）-软件中间件（Autosar为例）276 赞同 · 27 评论文章

中间件有了，只是我们和硬件完成了剥离，但在和其他模块的交互机制上仍然存在问题，这里先要聊下单播，组播和广播三个概念。

https://blog.csdn.net/qq_28657577/article/details/86487062

这三个概念，原本来源于计算机以太网通讯（就如软件定义汽车，现在车辆也用了这个概念）

单播(unicast): 是指封包在计算机网络的传输中，目的地址为单一目标的一种传输方式。通俗理解就是一对一通话，这种通讯方式稳定性好，但如果有多个人需要这些信息就不划算，每个人开一个频道就会占用很大的通讯带宽。

组播(multicast): 也叫多播， 多点广播或群播。 指把信息同时传递给一组目的地址。它使用策略是最高效的，因为消息在每条网络链路上只需传递一次，而且只有在链路分叉的时候，消息才会被复制。这种模式一般有订阅和发送方两个角色，只有订阅了，才会被发送，是介于单播和广播之间的一种方式。按需定制，效率平衡。

**广播(broadcast)*是指封包在计算机网络中传输时，目的地址为网络中所有设备的一种传输方式。实际上，这里所说的“所有设备”也是限定在一个范围之中，称为“广播域”。这种方式就是广场上用喇叭讲话，广场上的人都听的见。

整车现在采用了什么机制？

目前整车使用的一般是哪种？准确来讲应该是网关固定设计的单播，加独立CAN网内部的广播叠加的综合机制。

中间的是网关，旁边的都是独立的CAN网络或者其他网络，假设信息要共享，就会是这样

灰色连线内部如果要接受或者发送信息则都能够接收到（CAN的特性决定），如果要跨越几个控制器，就要经过上面一层的网关。**网关里面谁给谁发，都是预先设定好了的单播策略。**我们也称这种架构为signal oriented架构，面向信号的架构。

这种机制有没有问题，现在没有什么问题，因为发布即锁定，大家按照既定的来做就可以了。但如果需求发生变化情况就不同了。面向信号的架构，大家都依赖信号设计，而这些可不好改

为啥要用SOA呢？用了SOA有什么好处？

SOA是IT行业近年来典型的架构方式，大量的IT系统都是基于SOA实现的。而汽车领域采用SOA架构的一个主要原因就是能够加快车辆与互联网的互联互通。

• 大幅提升自动驾驶功能
• 便于实现高清地图的创建、更新及路线预测
• 便于实现车辆信息的上传以及云端指令的下达
• 快速提升系统与软件升级性能
• 有助于实现各种远程诊断、预诊断等功能
• 能够大幅提升影音娱乐功能的用户体验
• 能够实现不同平台间的各种App共享等功能
• 能够有效降低架构升级带来的复杂度

SOA架构下整车采用了什么机制？一重境修为SOC(Service Oriented Communication) 基于服务的通讯

简单讲，实际上是组播机制。具体说，SOC主要为了实现通信标准化，动态建立通信关系，连接信息孤岛。车载以太网协议架构中的AUTOSAR-SOME/IP就是基于SOA思想定义的通信中间件，SOME/IP是针对车载环境定义一套通信协议，可以达到屏蔽系统异构性，实现互操作的目的，SOME/IP可以直接用于实现SOC（但其他传输协议同样可以，例如DDS等）

当前整车架构多处于分布式阶段，通俗点讲就是“半吊子”你看着上图是不是和什么图片很像？

嗯，和CAN的结构很像，唯一的区别CAN的横条是广播的逻辑，而SOA的横条是组播逻辑，只是通讯上做了优化，那还有什么需要优化的？

车内所有具备以太网通信能力的节点离散的挂在网关上，如果没有域控制器、中央型处理器或者高性能处理节点。那很有可能每个节点的资源由于初期规划简单而不可能预留丰富的资源供量产后新增功能使用和消耗，故很难在此基础上实现功能重构。

这就引出了SOA的第二重境界

SOA架构下整车采用了什么机制？二重境修为SORS(Service-Oriented Reuse-shared Design）基于服务的复用共享式设计

在谈SOA架构的前提还是第一篇文章讲的，需要新的硬件架构来适配新的发展需求，如下图

过去分布式架构中，控制器数量都超过100个，所有的功能实现多是基于不同控制器之间传输信号来实现。软件定义汽车下，控制器数量大幅下降，针对少数控制器就可以单独的抽象出“服务组件”，最终形成面向服务的架构。

**很多时候EEA变革、SOA架构是割裂的谈的，其实两者是相辅相成的。没有EEA对控制器的集中化，SOA没有多大意义。**创造更大价值的主要还是Zonal架构变化带来的。SOA是和Zonal比较好的拍档，SOA有助于Zonal的实现。有时候能够降低通信的延迟，具备灵活可拓展的优势，降低测试成本和时间。SOA是一个长期演进过程，这中间并不容易。

以特斯拉为例，现在特斯拉Model 3是以类似CAN信号为导向的架构，还是以SOA为导向的架构？我觉得是一种中间状态。未来，SOA架构大概率也只能是特斯拉这样的车企去先践行了。因为SOA的落地同样需要的是组织架构的重组。绝大多数供应商只供应少数传感器和控制器，SOA是全局的，供应商是很难主导全局的变化。对车企内部来说也是一样的。各个部门和科室是割裂的，沟通效率不高，且即使车企有很强的内部协调能力，协调外部的200个不同的供应商也非常艰难。OTA也面临同样的问题，要协调那么多更新服务也不容易。目前大家都在给行业科普，但真正的实践和落地，说服领导，多半又只能看着特斯拉慢慢逆向和揣测了。

SOA架构的开发思想梳理

根据SOA软件开发方法，可从两个切入点开展SOA汽车软件平台的开发。 1)自下至上，从车辆基础功能/信号出发，将已有的应用功能逻辑/信号(eg:车辆车速信息)抽象或封装成服务组件，这类组件被称为基础服务层(Basic/Platform Service Layer)组件，具有最高的可复用性和可组合性，这些组件将为上层(业务服务层Business Service Layer)的服务组件提供最基础的支持。由整车末端硬件开始向中心硬件进行梳理和盘点，特定的硬件可以提供相同或者而类似的服务，例如，阳光雨量传感器就可以提供光照强度和雨量的信息，这样我们就可以抽象出来一个阳光雨量的服务，只要这个硬件在，我们的服务就会在，不受任何约束。之后可以继续向中心探索，挖掘硬件对应的功能、所提供的数据等，进行服务抽取。

2)自上而下，从整车业务逻辑和用例出发，结合各领域的核心业务知识，设计业务服务层(Business Service Layer)的服务组件；同时，遵循服务组件的复用性和自主性等原则，向下设计规划基础服务层(Basic/Platform Service Layer)的服务组件。由车辆既有功能和业务流程入手，例如整车防盗认证，会有各级防盗认证流程，期间会调用到很多的模块或者算法，比如随机化算法、防盗认证算法等，可以将这些算法抽取出来形成不同的算法服务。从一个个的功能业务链入手，分化抽离出服务库，最后可以逆向重建，即从服务库中挑选出一个个服务模块，通过排列组合的调用就将原始的功能业务场景无差的还原出来。

看起来，还是自下而上容易点，这样能保证穷举，所有现有功能可能都不会受到影响。

自上而下感觉容易有疏漏。或者说这个分析过程是同步的，同时自上而下和自下而上做冗余分析，然后看看推导出的基础服务层和基础服务组件是不是一致。如果一致那很好，如果不一致，再分析为什么不一致。在SORS开发模式下，OEM在平台/车型研发阶段将分析车辆本身拥有的一切软硬件资源，并提供重复利用的可能。OEM或授权的第三方可以基于服务库轻松开发新功能，快速完成迭代，并通过OTA技术部署到车端，持续提高用户体验。

SOC(Service Oriented Communication) 设计细节

通信行为：SOME/IP吸收了RPC机制，顺利地继承了Server-Client的模型，SOME/IP Service Discovery可以让Client灵活可靠的找到Server，并订阅感兴趣的服务内容，Client可以用Request-Response、Fire&Forget的模型访问Server所提供的Services；Server可以利用Notification推送给Client已经订阅的服务内容。由于以太网采用交换机的组网方式，拓扑内以太网节点的交互能够二层转发，网内节点可以动态的建立服务提供与消费的关系，不依赖于其他额外的机制和组件。例如，订阅机制，高精地图Server向外提供高精地图数据（Offer Service），ADAS控制单元想要订阅其车道线相关信息（Subscribe EventGroup），高精地图Server同意其订阅请求（Subscribe EventGroup Ack），而后Server开始发布高精地图的车道线数据给ADAS控制单元。再如，请求与响应机制，HU想要获取DVR内存信息，此时DVR是Server，HU是client，由HU向DVR发出request，DVR收到请求后，根据自身当前状态，回复response。

SORS(Service-Oriented Reuse-shared Design) 设计细节

SORS是基于下一代智能网联架构来实现的，主要是完成服务实现，并且体现服务复用性而进行的设计工作，使服务本身具备高内聚，服务之间能够低耦合，提高服务的可重用性，明确边界概念。

详细的SOA进的差不多了，我们开始下一个特别的话题OTA，欢迎看我后续文章

软件定义汽车（4）-OTA升级

接上一篇回答，软件定义汽车讲完SOA架构，基本上就完整了，但是软件定义汽车后的整车电气架构就引发了另一个重要的特性OTA升级功能。接着上一篇。

殷玮：软件定义汽车（3）-SOA架构171 赞同 · 16 评论文章

汽车OTA（Over-the-Air Technology，空中下载技术）,简单讲就和手机的软件更新或者系统升级是一个东西。比如IOS12升级等。

只要你有手机基本都经历过这种升级。之前说软件定义汽车就是要把汽车做的和手机一样，什么意思可以看我这个回答。

如何理解「软件定义汽车」？123 赞同 · 20 评论回答

核心是这个图，画的潦草了一些，这里面橙色画的都是OTA的部分，更新的一般是核心服务（固件）和软件两种。

另外虽然两者一致，但汽车的OTA升级难度远大于手机OTA，原因有两个

• 浅层的说，车是安全产品，对安全的要求较高。2000年以前并没有汽车的OTA，到2015年OTA技术才逐步实现了大部分软件的更新.
• 深层次且更重要的是，在没有在整车电气架构上体现软件定义汽车所需要的集中化，OTA是天方夜谭，因此OTA同样是互联网思维的一种渗透和体现。很多传统主机厂也能够对软件进行升级，只不过不能通过远程来完成，主要就是架构的受限。 但要推翻现有可靠性极高、平台化极高、安全性极强的架构，让很多传统主机厂为难。

FOTA和SOTA的区别

刚才说一般两种固件和应用更新。在汽车OTA里面。固件升级叫FOTA（Firmware-Over-The-Air，固件在线升级）软件升级叫SOTA（Software-Over-The-Air，软件在线升级）。

• FOTA，指的是给车辆下载完整的固件镜像（核心服务）可能影响所有应用程序（手机会变成砖头），影响较大
• SOTA，只仅发送需要更改的部分应用软件，只对小范围的功能有影响。（下载一个知乎应用）。

SOTA对整车的要求较低，一般你一个稍微高级点的ECU接一个4G网卡就可以实现简单的应用升级，由于影响范围有限，且大多是娱乐系统，单独并不大。但FOTA的实现（一般需要进行固件更新的都是高阶复杂的域控制器）往往涉及整车重要的控制器，包括车身、动力和自动驾驶系统，整车要求较高

OTA升级的意义

• 对客户而言，升级会本质上的提升其用户体验，区别就如同，老师大哥大和智能手机的差别。汽车功能的迭代会带来惊喜感。
• 对车企的整车销售来说，玩法更多。可以和手机和互联网产品一样，精简产品线，通过解锁方式进行释放，用更新方式进行增加。就如我这个回答（纯属搞笑）

如何评价国产特斯拉 MODEL 3可付费在线激活后排座椅加热功能？这是否说明功能硬件早已植入？1334 赞同 · 98 评论回答

• 对车企的质量保障来说，原来复杂的召回过程，现在都变得简单，特斯拉在收到各种抱怨后，对车辆的控制器策略做过多轮调整
• 对车企的整车研发来说可以缓解流程压力。整车的开阀锁定制度决定了G6到G5阀的阶段需要完成所有软件研发，但这对于自动驾驶，智能座舱这种软件来说都是不够的，有时由于研发周期过长，还有完成及过时的问题。OTA升级可以帮助整车在不影响发布的情况下，延迟1-2年的研发时间

OTA升级流程

OTA一般分为三步，第一步，生成更新包；第二步，传输更新包；第三步，安装更新。

云端生产更新包

OTA云端的框架结构主要包括五部分：OTA管理平台、OTA升级服务、任务调度、文件服务、任务管理。待升级的软件包一般由设备软件供应商提供，给到OTA服务营运方。软件包包括要更新的内容，全量还是分量，一个车型，一个批次，还是一个特定群体等，这些包被放在OTA云端服务器上开始交互。

知乎：天残

管端传输更新包

通过4G/5G网络建立车辆与服务器之间的安全连接，确保全新的、待更新的固件安全地传输到车辆的TelematicsUnit（也叫TBOX），上面运行着OTA升级管理程序（OTAManager）和升级代理程序（Update Agent）。

车端安装更新包

更新软件到执行的各个ECU，主要由上述两个软件完成

OTA Manager（左边的锁）是整个更新的核心，它负责连接车辆与OTA云平台的管理程序，管理车辆所有ECU的更新过程， 它控制着将固件更新分发到ECU，并告知ECU何时执行更新-在多个ECUs需要同时更新的情况下尤为重要。 OTA升级任务下发到车辆后，升级管理程序OTA Manager也必须判断车辆条件是否符合。对于不符合条件的车辆，升级管理程序必须中止升级任务并上报给云平台，合适的安全完成后，也要上报云端。OTA升级还需要能够灵活定义升级的具体范围，升级时机，升级内容，提示事项，失败后给用户的失败处理提示，提升大规模升级中的运营效率和运营体验。

另外，它实现了端云的安全通信，包括协议通信链接管理，升级指令接收和升级状态发送，升级包下载、升级包解密、差分包重构、对升级包进行合法性验证,还包括密钥证书管理服务，数据加密服务，数字签名服务等。等功能。

Update Agent（右边的锁）是为了兼容不同的车内通信网络和通信协议（包括CAN，以太网），以及不同OEM间各品牌车型的接口差异，进行封装适配的部分。应对不同的安全等级的域控制器（动力系统域、车身系统域、智能座舱域、自动驾驶域）的多个ECU，不同ECU有不同版本的软件。升级先后次序，依赖关系也各不想同。升级代理提供了统一接口，由OTA厂商负责实现接口，完成接口和业务逻辑的适配。

知乎：天残

从营运角度出发，一般会区分静默升级（库存车升级）和非静默升级（客户车升级）。非静默升级其中又分为普通升级和紧急升级，紧急升级一般是用于特别重要安全补丁的推送升级，车主知情但是无法拒绝。

客户导向的OTA设计原则

整个OTA过程大家可看到影响用户短期体验的是“管”（左侧的锁）（升级包下载中。。），“端”（右侧的锁）（升级包安装中。。）两个环节。下载的核心侧重是安全（不被篡改，损坏），安装的核心侧重是鲁棒（确保安装成功），两者都决定了速度（下载速度+刷鞋速度）。

整个OTA过程大家可看到影响用户长期体验的是“云”，包括丰富而定制化的数据包，无感的升级体验，过程的惊喜感。

我们分别看下这些内容的具体细节

OTA短期体验问题

OTA升级的安全考量

怎样保证升级文件被安全下载到车辆？升级文件如何能不被恶意替换掉？如何确保升级文件来自于车企自己的云端？从升级包制作，发布，下载，分发，刷写等环节，OTA需要从云，网络，车端来保证安全。

下载过程要安全，软件更新内容不仅需要认证，还需要加密，以保证数据在传输过程中不被仿冒和窃取。这就需要将标识密钥技术运用到OTA运行过程中。搭载标识密钥技术的车辆，在进行软件升级时，能够实现云端服务器、车端之间的身份认证，并对车和云之间的通讯数据进行加密，使数据能够以密态形式分发到车端，防止在通讯过程中数据被挟持和篡改，提高了 OTA 更新的安全性。

刷写过程要安全，硬件上需要专门的安全芯片进行校验、解码，一旦检测到安全芯片中的数据存在安全风险，数据会自动销毁。另外通过汽车功能域隔离，划分不同ASIL等级，通过冗余设计保证整车的功能可靠性，通过安全启动来保证可信的软件在ECU上加载启动运行，另外采用并行独立的OTA路径。

OTA过程的鲁棒性考量

在OTA传输过程中，外界干扰或者其他因素导致刷写异常或者中断，车载ECU必须支持软件回滚、断点续传、丢失重传等处理机制。另外还要处理刷写过程断电，刷写失败，刷鞋后不兼容等情况。

知乎：天残

整个刷写过程，一般都会是“一备份，一运行”的模式，一部分用于存储当前运行的程序，一部分用于存储备份程序。如果升级过程中发生错误，ECU内部自动回滚至上一版程序，防止车辆变砖头。自动驾驶软件类似，是“一运行，一后台运行”用来比较和测试相关功能，确认功能满足预期后，将后台软件替换至前台软件。

OTA升级的速度考量

速度主要由下载和刷写速度共同决定

• 下载速度没啥可说的，4G/5G网络下载，减小包大小，采用静默预下载等逻辑，提升速度
• 刷写过程特别涉及动力域传统ECU的刷写，是通过CAN网络进行安装包分发的。由于CAN传输速率很低，且CAN总线负载率要控制在30%以内，因此在带宽允许的情况下，尽可能采取采用并行刷写模式，选取刷写时间最长的节点优先处理等设计原则减少OTA升级时长。

OTA长期体验问题

OTA的包制作，升级管理，都是一个间歇性而长期的，OTA云平台包括升级模型管理，升级包管理，升级任务，升级策略以及日志管理

升级模型是用于定义设备模型基本信息和能力支持情况。升级模型一般能够体现一个车型下各个零部件ECU的依赖关系，例如多个零部件ECU直接软件包配套关系和升级顺序控制，对于升级任务在设备侧的准确完整执行非常重要。此外，升级模型还包含了升级规则的定义。升级规则可以用于描述升级流程中，用于允许升级能否继续进行的判定条件。在整车升级中，一般包括了一款车型在升级下载前，下载中，安装前，和安装中的判定规则配置。

升级包是在升级任务中，用于真正下载和安装部署的文件。常见的升级包制作处理包括文件压缩合并，生成特定的文件描述信息，文件签名和加密处理。许多设备闪存较小，升级包要能完成安装，需要尽可能地压缩大小。OTA平台在升级包制作中提供了差分生成的离线和在线工具。升级差分包之前，通过比较新旧版本之间的差异，生成差异文件。差分更新的核心技术是各家OTA供应商掌握的字节差分算法。

升级任务是OTA平台用于执行和监控一组设备的升级活动的集合。升级任务可针对特定范围的设备，使用相应的升级包和升级策略，进行升级任务创建，下发，监控，状态维护等整组活动的管理。升级任务的监控功能，提供了对一组升级活动中，升级任务状态，进度和结果的反馈。按照升级任务状态的状态，主要包含了成功，失败，升级中等设备的数量和各个状态下的比例。升级任务的控制功能，提供了对一组升级活动中，升级任务的启动，停止，暂停，恢复，重启，撤销等操作能力，实际上是维护了任务状态机的状态变迁干预能力。

升级策略是升级活动中的用于描述任务特征和目标设备升级行为的配置。升级主要会涉及到下载和安装两个阶段，升级策略中，一般会包含升级包下载策略和升级包安装的策略，以及异常情况下的处理策略。例如，在整车升级中，升级策略包括静默升级，常规升级和紧急升级的分类，也包括了升级包下载前，是否需要通知给用户下载确认的配置。

升级日志包括云平台的日志，车端与云平台通信产生的日志和车端升级程序搜集上来的日志。主要用于升级失败后的分析和支撑升级运维运营管理。

总结

元管端三个点，制作传输安全三个过程，首要安全，次要灵活，最后要速度。满足大家对功能迭代速度的诉求。这就是OTA。下一讲我们说说OTA行业解决供应商情况，以及蔚来、理想、特斯拉等热门车型的OTA架构升级情况。具体在这个回答里更新

汽车OTA哪家强？

OTA除了其本身可说道的意义外，更重要的是实现了这个功能的整车，一般都是在先进电子电气架构上有所创新的。因为就如我专栏说的软件定义汽车下的域控制器是OTA功能成立的前提条件。

OTA赛道入场券

目前完成软件定义汽车的公司，才能说我的OTA如何如何了。这里我们先看下提供对应域控制器服务的都有哪些供应商。

座舱电子域控制器领域，包括松下、博世多媒体、大陆汽车、三星哈曼、伟世通、阿尔派和电装，二线包括佛吉亚歌乐、现代摩比斯、Aptiv等。中国有德赛西威、航盛、华阳、博泰、亿咖通等。
智能驾驶控制器领域，包括博世，Aptiv、大陆汽车、日立、ZF、Veoneer、Magna、现代摩比斯、电装。中国有恒润、德赛西威等。

智驾域控制器向外对车，集成大大小小的ADAS功能和L4高阶自动驾驶驾驶功能。座舱域控制器向内对人，一般会集成仪表和车机，未来则会逐步整合空调控制、HUD、后视镜、手势识别、DMS，甚至包括T-BOX和OBU。集成了多少也就证明多少可能存在OTA的可能。

车企和Tier1谁来做OTA方案，主要看两家的合作模式。如果Tier1自己与上游芯片供应商和下游算法供应商合作，做解决方案，诸如大陆ADCU、采埃孚ProAI、麦格纳MAX4，那这个OTA估计就是Tier1来做。又或者Tier1只帮助整车厂处理硬件生产、中间层以及芯片方案整合业务。那OTA的开发方就是整车企业。

接下来介绍几个参赛者：

小鹏汽车

小鹏G3搭载自主研发的Xmart OS智能系统，但是在小鹏G3的供应商清单里没有发现OTA的迹象，核心驾驶辅助功能是由bosch开发的，因此暂时只是支持部分应用OTA升级

小鹏汽车之后宣布与德赛西威签署战略合作协议，共同研发L3级别自动驾驶系统。小鹏汽车成为国内首家预定德赛西威最新款自动驾驶域控制器的主机厂。因此在小鹏P7自主泊车系统的释放，但尚未发布Pilot功能，也说明了德赛西威集成的英伟达平台控制器已经具有OTA功能。小鹏汽车目前在中美两地均有自动驾驶团队，总人数大概有100多人。其中美国会偏重算法研发，而中国则偏重将整套自动驾驶技术量产装车方向。软件更新的后期可期待。

蔚来

由蔚来北美产品及信息安全团队负责的 ES8 和 ES6架构，有超过 60 个 ECU，采用了千兆以太网作为内部传输总线，通过一个高性能的软件操作系统，基于智能网关打通与所有 ECU 的通信，蔚来将整车电子电气架构划分为底盘域、车身域、辅助驾驶域、动力域和信息娱乐域五大功能域。目前中央控制器仍然选用的德赛西威的方案。

2019年初蔚来OTA引发长安街交通秩序事件。 具体内容是一位蔚来车主因为挂 P 档升级系统导致车辆黑屏无法启动，因此在路边停了一个多小时。而刚好事情还发生在帝都长安街堵车进修，更是引来了警察的警惕和车主的无奈，以及网络上大量吃瓜群众围观。

目前OTA的情况在多轮升级后稍稍缓和一些。

理想

理想目前核心车型—理想one采用的辅助驾驶芯片来自Mobileye（EyeQ4），而辅助驾驶软件则是与易航智能合作研发。其辅助驾驶硬件相对于业界水平不算领先。但这次合作，理想的辅助驾驶不仅将有巨大的进步，这一次三家新兴造车厂也非常有默契的统一了方案。理想也准备用英伟达的方案，并进一步选择最新的Orin芯片，因此理想汽车整个辅助驾驶系统也将发生根本性变化。

特斯拉

特斯拉的三款车的电子电气架构在不断变化，从 Model S 的分布式到 Model 3 的集中式架构，ECU 控制模块越来越少，为便捷的实现整车 OTA 奠定了基础。2012Model S 的上市，特斯拉成了首个实现 FOTA 的汽车品牌。但这个时候特斯拉使用的是基于哈曼旗下子公司 Red Bend 提供的技术支持来实现的。和其他供应商一样的下场，后来 Model 3 上市的时候，FOTA这一块，特斯拉完全采用了自主研发的方案。

特斯拉的OTA几乎涵盖了整车的方方面面、大大小小的环节。小到中控屏界面、操作按钮、娱乐系统，大到关乎驾驶的刹车系统、油门踏板力度等部分，几乎都可以实现OTA升级，让汽车在每一次升级过后都能给你带来新的惊喜。

ID.3

2018 年 10 月,基于大众MEB 平台的首款车型大众 ID.3，将可以减少模块数量，通过以太网而非传统的 CAN 总线连接各种组件并进行 OTA 升级。该平台采用名为「E3」的电子电气架构，将车辆大部分的 ECU 集中到核心的中央计算平台。和特斯拉 Model 3 一样都实现了相对激进的高集成域控制器方案。ID.3平台作为大众第一个进入软件定义汽车的平台，一直备受瞩目，后续对此会进一步展开

奥迪

奥迪已经上市的全新款A8，最引人瞩目的亮点是其搭载了L3级限定条件下自动驾驶功能。核心采用aptiv中央驾驶员辅助控制器（zFAS）目前这个平台是否支持OTA还待确认。

长城WEY,哈弗

Aptiv和长城系列车型都有很多的合作。目前的柠檬平台从一开始就考虑了智能化的需求，特别是其中的第三代哈弗H6的电子架构，将整车分为四个域：影音域、ADAS域、动力域和车身域，都可以通过FOTA进行升级优化。WEY的车型虽然没有更升入探究，但估计也不例外。

目前大家都在试水阶段，但可以看到整车厂进行OTA升级的软件服务开发是一个趋势。最后OTA的强弱，服务管道应该会成熟，核心的还是看平台的灵活性和更新的想象空间。

汽车是怎么开发出来的？-浅谈汽车开发流程

你知道汽车是怎么开发出来的吗？

你的脑海中很可能浮现出来这样一个画面：一个非常有艺术气息的设计师，在草图上帅气的描绘着看起来非常犀利的线条。

对，但不全对。

对于汽车工程师的我而言，眼前浮现的是：

\1. 脏兮兮的设计师在刮着第5个版本的比例油泥模型

\2. 工程师在更新着第145个版本的数模。

\3. 设计师，工程师们聚集在样车前，看着自己参与设计开发的工程样车，自豪的咧着嘴笑着，还一边嘴欠的抱怨着：这大灯真TM难看，内饰也太挫了

\4. 工程师一遍遍在路试场地上急加速，急减速，快速过弯，眉头紧皱，喃喃道：怎么复现不了刚才那个异响呢

\5. 项目正式量产后，所有项目组的成员集体在几台崭新的车前合照，一起喊着“茄子”

诚然，一辆新车型上市蕴含着无数人上千个日日夜夜的心血。

汽车作为与人类接触最密切的人类文明史上发明的最复杂的产物之一，已经有一百多年的历史。相应的，其开发流程，经过这一百多年的发展，也已经非常完善了。

目前主流的全球汽车制造商，如通用，大众，丰田等，都有自己的开发流程。但是仔细看下来，其思路都是非常一致的。

大众汽车的开发流程：

通用汽车的开发流程：

福特汽车的开发流程：

丰田汽车的开发流程

不知道各看官发现了没，虽然各个主机厂的流程具体细节和表现形式上有差异，但是其总体思路是一样的。

那就是都是按照下图来安排的。

下面我就展开跟大家探讨一下。

第一个阶段就是前期项目研究阶段，主要就是车型定位。

这个阶段主要任务是定义该车型的价位（是几万的代步车还是十几万的中级车），风格（家用还是运动），定位人群（都市白领还是高富帅），研究该层次的主要竞争对手，销量大小，利润率如何，预计整车成本和整车利润率，这个阶段决定了要不要继续开发这款车型。

举个例子：我的一个朋友小W，总跟我抱怨找不到女朋友。我劝他给自己做一下定位，长相如何，收入如何，家庭如何，是否有房有车，对自己有清晰的定位，然后在决定自己能够匹配到的女友的层次。如果你给自己的定位是普通屌丝，偏偏要去追海龟白富美女神。虽然不说是没有可能，但是用脚趾头去想也知道可能性很低的。（知道政治正确很重要，大家轻拍）

车型定位确定之后，就要进入概念开发阶段了。在这阶段主要是造型设计和工程的前期架构搭建。

根据车型的定位，来确定整车外观的风格。这时候就该我们的设计师上场了。设计师从前期草图设计，小的模型制作，最后制作出1:1模型，交给领导评审。领导说：好看。接下来就按照拍下来的方案继续开发了。

造型设计，务求能打动定位人群。现阶段中国客户购车时虽然已开始理性起来，较少会因为一款车的外形就义无反顾看要买，但是往往会因为一款车外形不符合审美而放弃购买这款车。

在这里跑个题：大家总说国产车型太丑，吐槽国内的工业设计水平落后。其实看到这里大家可能也意识到了，其实未必是设计师水平本身水平问题，更可能的是拍板的领导审美水平令人捉急，选的方案，只是符合自己的审美，最终量产时，自然让人忍不住吐槽。

下一个阶段就是产品开发了。

根据整车的初始的整车目标（成本，重量，性能目标，如安全，加速性能，底盘操控性能等）打散到每个系统，每个零件。产品工程师拿到要求后按照要求去开发产品。

初始设计后，再经过几轮的设计评审后，产品就可以正式开模去制作零件了。

零件出来以后就可以做产品验证了。

产品验证包括零件级验证和整车级验证。

零件级验证，即台架性能验证。台架验证会以最苛刻的试验条件去验证。所有零件都通过验证后就可以制作样车了。样车出来后安排进行整车测试。除了专项的测试，如整车碰撞试验，进排气试验，整车振动噪音试验（NVH）外，还需要做整车道路路试验证。在整车道路路试验证阶段，让车辆按照各种典型工况进行强化疲劳耐久，如高速工况，碎石路工况，方坑工况，腐蚀工况等。对整车进行极限工况的考核。

上述试验通过后，基本上产品验证阶段就结束了。

下一个阶段是试生产。

之前试制的样车是使用简易工装和简易工艺，在非生产线上搭建起来的。试生产阶段是要在生产线进行使用正式工装和正式工艺上进行，考验冲压，焊接，涂装和总装四大工艺。

一开始造的速度（即生产节拍，一般用JPH表示每小时下线车辆来表示）比较慢，所有的工艺慢慢磨合熟悉后，节拍慢慢提高，即所谓产能爬坡阶段，慢慢的在达到一开始规划的产能要求，这时候就可以正式量产了。

其实整车的开发流程像极了青年男女相识相恋到步入婚姻殿堂的过程。我稍微解释一下就明白了。

前面说了，前期工作阶段就像是给自己定位，选择什么阶层的对象。

概念开发阶段就是为了满足意向对象的眼缘，来打扮自己，提升自己的颜值，提高形象分。

产品开发阶段像是一对青年，彼此不反感，都同意进一步接触后，这就是就可以相约看看电影，喝喝咖啡，展现自己优秀的一方面，也加深对对方的了解。

产品验证阶段就是彼此接触了有一定了解了。这时候就需要进一步考验了，比如收相约一起出游，旅行等，考察对方的生活习惯。

试生产阶段就是一对恋人的关系进一步发展，已经同居了。这时候就需要两个人一起面对柴米油盐，也看到对方打嗝放屁，一起做一些重要决定。

如果顺利通过了磨合阶段，就可以步入婚姻殿堂了。

至此，一切功德圆满。

---

---

在智能化赛道上，如何看待新造车势力与传统造车势力间的博弈？终局如何？

新造车势力与传统造车势力间的博弈实际上是快慢思维的博弈，在智能化的声浪之下，传统车的慢思维时常遭致口诛笔伐。但是新造车势力快思维下频发的安全事故也同样没少制造话题热点。个人以为两者都有些矫枉过正。

快慢之间，各有糟粕，谁能率先“师夷长技" ，谁就能在智能时代的终局取得胜利。

智能汽车是一个充满着矛盾的产业，一方面，涉及量产的部分属于传统制造行业，关注安全，关注质量把控，关注成本控制。一直以来的文化都是精益而谨慎的。另一方面，涉及人工智能，互联互通的部分又属于互联网和机器人行业，承载着科技的前沿，寻求创新和颠覆。两个几乎对立的思维出现在了一个产品上。这种矛盾的调和构成了两方博弈的主线。

我专门做过几个时间线，回顾整个智能化发展的历史，在大的周期上，我们处在第三次工业革命的收尾和第四次工业革命的开始的阶段，而从小周期看，第三次工业革命收尾的核心标志对于汽车产业来说就是围绕芯片，域控制器，智能算法而构建的集中而灵活的硬件架构，软件架构和人员组织架构，为四次革命的关键“大脑”提供一个有机而完整的“身体部件”。2015年前，上一个周期内传统主机厂占了先机，而新的周期内无疑是新兴主机厂的先机。

但我个人更关心的是下一个小周期2025年后我们要思考的问题，也就是在快迭代走向极致后，智能汽车如何在新环境下重新保障安全。这种安全与迭代的交替发展与调和构成了两方博弈的主线，虽然我一直认为慢安全和快迭代之间并不矛盾同样重要，但我不能和稀泥的看这个问题，传统车厂不能再把过去对于安全的理解强加到现在，认为这是和新势力博弈的筹码。下一个阶段的安全理解虽然目标一样但体系可能大相径庭。**慢就是慢，慢和安全划等号在过去是成立的，未来的安全理念并不一定适用。**总的来说传统造车势力非常吃亏，过去的积累反过来成为很大的累赘。但也必须看到传统企业这几年为了赶上这场浪潮也是下了决心的，结果尚未可知。

**智能赛道进入四次革命之后，像人一样兼具灵活和安全的人工智能无疑是主线，而连接这两个概念的就是智能汽车，终局必然在第四次革命结束的时点，过程的愈演愈烈几乎不用过多的分析。**我并不想去猜测传统还是新兴造车谁会胜出。可能最后赢家是美团或滴滴也说不定。核心还是谁真正理解了时代和用户的新诉求，并切实的作出了改变。传统车家大业大也好，新势力轻装上阵也罢，各有千秋，但时代永远只会给发挥优势，规避劣势，努力适应其发展规律的企业投去橄榄枝。

未来汽车如何发展？随着电动化、智能化加快，哪些跨界技术会应用到汽车这一最有集成效果的载体上？

泻药，如果手机已经算是一个不错的创新载体。那么拥有同样属性的汽车也必然是下一个跨界科技的井喷点。

**第一个需要回答的，什么东西可以成为一个创新载体？**普罗大众实际上每天长时间接触且拥有社交属性的实体都有这个潜力。比如手表，手机，衣服，眼镜，耳机，笔记本等，接触的时间越长潜力就越大。台式机有没有可能？老实说没有，很少有人能够在社交场合看见你的台式机。钥匙圈行不行？不行因为你一天没多少时间接触这个东西。手机长期使用且拥有社交属性，因此大量技术在手机这个载体上不断被发展。

而汽车同样是一个新兴的载体，虽然各项属性上同手机相比各有短板和长版，但的确是一个值得探讨的平台。我们开些脑洞思考下

变色玻璃VS车窗

和同行打听，电子变色玻璃应该在车窗满足车规级要求和安全驾驶上应该还有一些问题，但是看这个玻璃应用于车上，可以省去不少安装繁琐的反射板和茶色玻璃的功夫。还是很需要的，建议突破。

投影仪VS激光LED车灯

目前激光投影技术已经被逐步升级，用在车辆灯光的使用上，除了控制日常照明光线的场景适应问题，更多的在自动驾驶中方便车辆和交通参与者的沟通，以及提升差异化的社交（车辆皮肤）

这里投影仪技术还有一个衍生的重要应用汽车HUD技术

这项技术也正在变得流行

手机电池VS纯电汽车续航

手机经历了换电，有限充电，无限充电，嗯嗯，汽车作为一种”超大手机“，同样的故事，也在同步产生。手机有电池焦虑，汽车的焦虑更大。

换电池板技术

快充技术

无线充电技术

充电技术往往对车辆的位置精度有很重要的要求，因此一些对接技术往往也非常重要

座椅VS汽车座椅的外延

不同行业对于座椅的考虑，都可能在车上座椅中实现，比如舒适的人体可调节工程学设计，按摩座椅，加热制冷座椅或者是可以监控你身体状况的座椅。

蔚来女王座椅

耳机VS立体声与整车隔音

我们都知道过去我们通过材料来进行耳机隔音，目前流行根据发出反向的声波从而让噪声抵消的主动降噪。过去的车辆和耳机做着同样的事情。

整车的主动降噪技术，让你的车辆成为一个耳机

针对每个座位的环绕立体声

OLED曲面屏VS整车屏幕的布置

一种我们可以想象一下，如果整车外壳可以变化（OLED或者水墨屏），那是不是汽车厂可以考虑下贩卖整车皮肤，这个在潮玩界已经司空见怪。

从内部看，目前已经有试点应用的透明座舱实践透明A柱

以及目前已经有些泛滥的车机屏幕的OLED化

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KEnnar4n-1657816559662)(data:image/svg+xml;utf8, )]

家庭智能音箱VS车辆小助手

是不是用小米的已经习惯使用语音控制自己的家居设备，实际上车上这样的角色也变得更多，如果你对自己车上的功能不熟悉，或者驾驶过程中没有心思操作复杂的设备，车辆小助手对人的贡献是非常大的。语音识别技术在车辆这种安全应用里的潜力甚至大于智能家居。

手机传感器VS整车传感器

手机和汽车都安装了非常多的传感器，连手机都用上了激光雷达，这几乎是智能汽车领域的一个梗，手机作为传感器更多的是为了和用户完成更好的交互，偶尔考虑下环境。而车辆除了要和用户形成良好的沟通外，还要做好对于环境的理解，从而进一步保证用户的安全。

作为自动驾驶工程师，谈智能汽车的传感器估计能讲个几天几夜，包括激光雷达，毫米波，GPS，惯导，你会发现手机用过的，车辆几乎都会用，手机不用的车辆也会用，智能汽车可以讲的故事更多。

殷玮：传感器攻防战-一文汇总自动驾驶的那些传感器66 赞同 · 1 评论文章

手机变成了电脑VS汽车变成了家

当车辆可以自动驾驶，那么人在车里就更像是在房间里，任何房间的定位都有可能出现在车里，具体可以看我这个回答。

假如实现无人驾驶，你最想在车上实现的功能或者场景是什么？17 赞同 · 0 评论回答

当车辆变成房间你会想到什么？

总结

智能驾驶，智能座舱都是智能汽车在这一块的集中体现，看着手机的发展对于理解汽车的发展会有很强的借鉴意义，另外汽车作为一种更为大型的设备，其外延可能比手机还要深远，如果大家有兴趣深入理解其他应用场景可以看我之前做的几个回答。

5G 通讯技术会给汽车行业带来哪些变革？23 赞同 · 7 评论回答

自动驾驶大时代智能座舱会有什么样新的发展趋势？44 赞同 · 4 评论回答

传感器攻防战-一文汇总自动驾驶的那些传感器

横看成岭侧成峰，远近高低各不同，不识庐山真面目，只缘身在此山中。

用苏轼的《题西林壁》最能形象的描述自动驾驶的那些事。从技术工程师，到启动辅助驾驶的客户爸爸，再到高校政府。从学科体系，量产实践，司机感受再到道德法律，从多个方面切入自动驾驶话题都有一番不同的光景。这也是自动驾驶作为一个边缘学科与行业独具魅力的地方。

做传感器攻防战这个系列，初衷是说，对自动驾驶传感器的系统理解，是切入自动驾驶的一个不错的位置，由这个点开始纲举目张，我们能够较为简单的去理解整个自动驾驶的全貌。也尽可能促使，不陷入单个小山里，而忽略了庐山的真面目。

我的回答里很多会连接一些我相关联的回答，回答之间的跳跃，除了必要的补充，有时也是换一个角度看同一个问题，看远近高低才能呈现不同的风貌，对理解一个跨界的话题来说是有帮助的。

更新这个系列，源于下面这个回答，目前也已经更新这个回答的部分链接，这个回答看上去更完整一些，嗯嗯。

自动驾驶汽车涉及哪些技术？444 赞同 · 27 评论回答

这个回答里传感器的部分实际是由一张图串起来的。通过频率的分布，我们几乎可以看到自动驾驶，辅助驾驶甚至人工驾驶所存在的所有传感器，有些能测距，有些能接收可见光，有些能承载信息流。

由这张图扩展了几个关键传感器的内容，实际还有地图V2X后台体系，激光和超声波相机还有些内容没有补充完，可以做的内容非常多，根据行业新的信息我会持续增加，并替换原来可能过时的内容。

戚继光针对倭寇摆出的鸳鸯陈，不知道为什么和传感器布置也有点像，兵种配合相互支援，只是应对的是不确认的环境而已。

想想很有意思，每种传感器都有短板，因此相互配合就非常重要，而鸳鸯阵的布置和自动驾驶有思路上的共同点。（上面这个图是看着有点像哈）

惯导居中“指挥”负责支援其他所有传感器（激光，视觉，GPS等），为他们提供感知间隙和失效过程中的空间位置偏移量（车转了多少度，走了多少米）

殷玮：传感器攻防战-惯导IMU97 赞同 · 10 评论文章

GPS居中负责支援所有信息类传感器（地图/V2X等），为这些信息类传感器提供必需的绝对定位信号，从而获得具体的信息，并和惯导组成稳定的“中军”

殷玮：传感器攻防战-GPS26 赞同 · 3 评论文章

咋么看，咋么觉得两张图很像，是不是天下很多思路都很相似

地图和V2X构成了阵型的“狼筅”二将，动静态信息在远距离提早发现，提早处理，接敌与远距离，保证给整个系统足够的时间做出舒适，安全的判断。

殷玮：传感器攻防战-高精度地图引擎43 赞同 · 4 评论文章

殷玮：传感器攻防战-TBOX（5G/C-V2X）车联网传感器24 赞同 · 9 评论文章

视觉是一种泛用性非常好的传感器，就是“长枪”手，是陈型进攻主力，虽然难度很大，但是其巨大的信息含量，足以支撑其整个局部感知的中流砥柱

殷玮：传感器攻防战-摄像头（1）65 赞同 · 16 评论文章

毫米波是一种良好的支援传感器，就是“镗钯”手，是陈型掩护的主力，虽然不一定能够提供非常高分辨率的高维信息，但是关键的距离和速度信息是非常准确地，是不错的兜底捡漏的好手。

殷玮：传感器攻防战-毫米波雷达211 赞同 · 31 评论文章

激光雷达就是“盾牌”手，是整个陈型防御的主力，虽然非常昂贵笨重，但是其准确的距离信息和较高的分辨率，为所有传感器提供了最后的安全冗余措施。

殷玮：传感器攻防战-激光雷达（1）102 赞同 · 10 评论文章

万事都相同，希望这种解读，能对大家体系化的理解自动驾驶传感器有点帮助。

汽车行业软件工程师发展前景如何？与 IT 行业或互联网行业的软件工程师相比如何？

当前智能汽车行业处于风口，就像当年智能手机行业一样，所以当前的汽车行业软件工程师发展是非常不错的。

本人一直在汽车行业从事软件开发，工作经历大概是：

1、从最初的国内tier1做车身控制器

2、外资tier1做TCU（变速箱）控制器

3、HW做车载激光雷达产品

4、造车新势力，做智能驾驶前沿技术

几段工作经历，均是从事汽车基础软件的开发工作，所以能深刻感受到软件定义汽车的这句话的内在含义。

楼主现在拿到了底盘控制ABS系统或者ESP系统软件开发岗位offer，那应该就是像Bosch这样的一级供应商的工作机会了。但是ABS和ESP系统还是属于传统汽车ECU开发，其实相当于还是嵌入式软件开发，这主要就包括传统autosar基础软件开发、通信、诊断之类的。现在传统autosar已经成为汽车行业MCU的标准软件开发架构，市场上对懂传统autosar的人才，工资也开的很高，所以也还是非常不错的。

另外现在智能汽车行业还会有和互联网行业融合的技术领域。比如：复杂域控制器的操作系统OS、芯片多核hypervisor技术、汽车OTA升级技术、智能驾驶技术、智能座舱技术。这些技术会更加能吸引互联网人才。

本人现在的工作岗位身边就有很多来自阿里、百度的互联网行业人才，他们过来会从事一些操作系统技术开发、智能座舱VR之类的技术开发工作。现在汽车行业是越玩越花，汽车已经不仅仅是当初的机械移动终端，在汽车里面玩游戏、看电影都是可以的。所以汽车软件行业也释放了很多的就业机会。

总结：

汽车行业是风口，但是汽车行业软件技术其实分了很多的领域，已经和互联网深度融合。汽车行业未来的核心技术将会是操作系统OS和多核高算力域控制器芯片，本身传统Autosar也属于是汽车行业的一个标准操作系统，只不过它是运行在传统的MCU中。现在的多核高算力域控制器SOC不会跑传统autosar，而是更加适合的Adptive Autosar还有像Linux、QNX这样的操作系统。

总之，进入汽车行业做软件开发是非常不错的机会，其他汽车技术领域等入了行再慢慢学。

---

---

跟你以前做的会大有不同。

1、没有类Linux OS的支持。汽车电子产品要么用行业中采用的RTOS，要么是裸奔。

2、需要熟悉汽车以及相应控制原理，还要熟悉汽车软件相应标准、协议，如ISO26262、OSEK、AutoSAR、ISO14229等；

3、需要熟悉车载电气、网络知识。

4、要适应更严苛的测试，一个部件动辄数千项的测试项，对性能要求很高：尤其是可靠性、实时性。

5、项目周期长，产生效益需要更多的时间。

总之，这是个不错的行业，需要长期坚持才能出成绩。

---

---

浅谈下如果题主选择的是应用层的开发而不是底层。汽车软件开发与普通的互联网软件开发差别较大，更多涉及汽车本身的功能特性，如果题主进入该行业，需要对汽车的很多基本特征进行深入学习才能最终在该行业站住脚。

至于该行业内部的软件开发，个人认为创造性要比互联网低很多，代码生成如今基本已经不靠程序员编写而是基于模型的自动代码生成，汽车行业开发看中的不是你的创造性，当然这个也很重要。更重要的是功能的可靠与安全性，产生的代码需要经过反复的认证与测试。

至于底层的开发，汽车系统也有很多规定与架构，这也是与其他行业所不同。

至于发展前景，目前可以这样说，大部分主机厂不太具备该水平，但未来始终是一个方向，所以还是很有前景的，尤其在接下来的数年内。不过汽车行业的整体工资水平就呵呵了

---

---

浅谈下如果题主选择的是应用层的开发而不是底层。汽车软件开发与普通的互联网软件开发差别较大，更多涉及汽车本身的功能特性，如果题主进入该行业，需要对汽车的很多基本特征进行深入学习才能最终在该行业站住脚。

至于该行业内部的软件开发，个人认为创造性要比互联网低很多，代码生成如今基本已经不靠程序员编写而是基于模型的自动代码生成，汽车行业开发看中的不是你的创造性，当然这个也很重要。更重要的是功能的可靠与安全性，产生的代码需要经过反复的认证与测试。

至于底层的开发，汽车系统也有很多规定与架构，这也是与其他行业所不同。

至于发展前景，目前可以这样说，大部分主机厂不太具备该水平，但未来始终是一个方向，所以还是很有前景的，尤其在接下来的数年内。不过汽车行业的整体工资水平就呵呵了

华为能否成为下个博世?

2020年，整个汽车行业发生着前所未有的变革。“软件定义汽车”是今年的关键字，传统车企，互联网新贵，造车新势力都纷纷踏入汽车行业，将彻底改变汽车行业过去百来年的格局。

在今年的北京车展上，华为在汽车行业的雄心壮志正式对外宣布，他立志将成为智能电动车时代的“博世”，正如博世在传统汽车行业的霸主地位一样。

华为汽车BU于2019年成立，不过早在2014年华为就开始在车联网领域有所布局。到目前短短几年时间，已经形成了五大领域产品布局：智能驾驶，智能座舱，智能电动，智能网联，智能车云。用华为的话说，在ICT（信息与通信技术）领域的积累，现在转移到汽车行业中并非难事，并且可以很快形成技术优势。

智能驾驶解决方案

华为的智能驾驶解决方案核心是智能驾驶计算平台MDC和雷达等硬件部分。

MDC(Mobile Data Center)移动数据中心定位为智能驾驶的计算平台，搭载智能驾驶操作系统AOS，VOS以及MDC core，支持L2到L5级别智能驾驶，可针对不同的应用场景开发出不同的智能驾驶应用。2020 年2 月，华为MDC 智能驾驶计算平台通过ISO 26262 车规功能安全管理认证，这意味着华为相关产品可以满足汽车行业的高安全和高可靠需求。

华为MDC平台

在智能驾驶硬件部分，华为在武汉有一个光电技术研究中心，目标是短期内开发出100线的激光雷达，未来有望将激光雷达的价格降低到100-200美元；同时华为在射频领域有深厚底蕴，在毫米波雷达上也有望突破博世，大陆，海拉目前形成的垄断。

智能座舱解决方案

华为智能座舱的核心卖点在于鸿蒙车机OS软件平台和智能硬件平台。

鸿蒙操作系统OS主要面向车机应用，共包括语音，音效，视觉，AI等7大核心功能。OS接口支持3屏显示，7摄像头输入。华为智能座舱融合了出游，通勤等出行场景，拥有多项交互功能如人脸识别，信号灯提示，AR抬头显示等，可实现手机和车机的无缝对接，在未来，华为将为车企提供Hicar车机产品。

华为HICar

不同于CarPlay 现阶段的“投屏功能”，华为Hicar将手机的应用和服务延展到了汽车，让汽车和手机、其他IOT 设备之间实现互联。通过华为HiCar 功能，车主仅使用一部华为手机即可了解包括里程保险、车辆位置等车辆状况信息。

智能电动解决方案

智能电动是与传统供应商竞争最激烈的部分，包括电驱动系统和车载充电。

华为的电驱动系统包括两款产品：一款是融合电机、电机控制器、减速器的三合一电驱动系统，另一款是集成了电机、微控制单元MCU、电源分配单元PDU、车载充电机OBC、直流变换器DCDC、减速器、电池控制单元BCU 七大部件的多合一电驱动系统DriveONE，实现了机械部件和功率部件的深度集成。

华为七合一电驱

其中DriveOne系统可提供120kw或150kw的功率，重量轻，120kw系统只有65kg，体积比竞品小15%。华为的DriveOne系统核心竞争力在于深度融合。在电驱动系统轻量化，平台化，智能化的背景下，深度融合模块化是大势所趋。比如特斯拉旗下Mode3动力系统就已经向多合一演进：3+3的模式，即电机+电控+减速器和OBC+DCDC+PDU的模式，华为的七合一系统在这方面已经走在行业前列。

智能网联解决方案

5G是华为的最大卖点，华为的智能网联系统将基于5G，推出其V2X芯片，以及T-BOX。

华为在 2019 年的世界移动通信大会上发布了最新的 5G 多模终端芯片 Balong 5000，这款通信基带芯片体积小、集成度高，能够同时实现 2G、3G、4G 和 5G 多种网络模式，同时也支持V2X。华为的T-BOX也依据5G的优势，在多款车型上实现了量产，比如东风风神以及北汽新能源。

智能车云解决方案

华为的智能车云与其智能驾驶和智能网联一起构成了闭环的车路云协同生态系统，将人，车，路，网络连结在一起。

华为的云服务称之为“华为八爪鱼“，该平台提供数据、训练和仿真三大服务。包括自动化数据标注、场景挖掘、算法训练和优化等。在9月份华为发布的车云服务2.0版本上，华为智能车云包括四大服务：自动驾驶云服务，高精地图云服务，车联网云服务和V2X云服务。

云服务这块，国内以阿里云和国外微软云从业较久，受众比较广泛。华为云目前已经有了江淮，长安等客户。

*华为竞争力几何？*

跟其他一线汽车供应商上百年的历史相比，华为汽车只能算是新入局者，但是却不会有车企将华为视为汽车行业的新人。华为究竟有哪些优势，让其他的竞争者都感叹鲶鱼来了？

依我看，华为在汽车行业内的竞争优势主要体现在以下两方面。

华为核心竞争力之计算平台

在智能电动的浪潮下，汽车架构将从“电子+电气”转换为“通信+计算”，汽车的重心将转移到通信架构和软件算法上，而这些恰好就是华为积累所在。华为在这些领域的优势就体现在智能驾驶MDC平台，智能座舱鸿蒙平台，智能车云平台上。

MDC架构

依托于这三大平台，最有可能成为华为在汽车行业的核心业务的是车联网和智能座舱。

华为早在2014年就有了车联网实验室，利用其擅长的通信设备和技术跟长安，上汽，广汽等本土车企展开合作，将自己的通信模组，车机系统，车联网TBOX搭载在一些车型上。

零部件层面的合作对于车企主要是看中性能和成本，华为可凭借技术和制造优势打破外资垄断。华为在智能座舱和车辆网主要瞄准增量部件，包括TBox、AR-HUD、HiCar等产品。以TBox 为例，凭借华为在5G 优势可以在下一代T-box 上实现快速推广。

华为智能座舱

对于智能座舱来说，车载智慧屏，和AR-HUD决定了智能座舱的最终模样以及使用场景。华为的座舱解决方案优势在于性价比高，华为方案目前可以让汽车的挡风玻璃将成为显示面积达到70寸的ARHUD高清大屏，7.1声道环绕立体声，用户可以在车内开会，打游戏看电影等。

华为核心竞争力之操作系统

软件定义汽车背景下，操作系统是汽车生态发展的核心。华为目前在鸿蒙OS的基础上形成了三大操作系统：AOS智能驾驶操作系统，HOS智能座舱操作系统，VOS智能车控操作系统。之所以说，操作系统将是华为在汽车行业的核心竞争力，是两方面原因：

1， 汽车行业内的公司普遍重硬件，重生产，而轻软件。大多数公司软件能力偏低，既没有成熟软件团队，更没有自己的软件系统。而互联网公司华为则不缺软件工程师，更有自己成熟的操作系统和软件架构。

2， 生态。鸿蒙系统已经形成了生态，鸿蒙是全世界第一个面向全场景微内核的分布式OS，其初衷是为了提升操作系统的跨平台能力，包括支持全场景、高实时和高安全性的能力。华为一直坚持“平台+生态”战略：华为既提供完整的操作系统软件，也提供全套工具链。华为在MDC 平台硬件上，有智能操作系统AOS、VOS 及MDC CORE，还配套提供完善的开发工具链，如Mind Studio（支持AI 算法开发）、MDC Manifest Configurator（基于AUTOSAR 规范ARXML 配置工具）及其他诊断、可视化调试工具等。

*华为&博世*

华为高调宣称自己的对手为巨头博世，两家公司一家是百年传统豪强，一家是跨行新秀。现在让我们从多方面来观察一下两个“巨头”在几个领域的布局和竞争力。

Ø 电驱动业务

博世在电驱动硬件的生产和制造方面一直是行业领头羊，即使华为后来居上，但是制造这种东西，始终就是靠经验积累，华为存在天然劣势，敌不过博世百年积累。博世在电机，BMS系统，IGBT，充电技术，E-CVT等都有上十年经验了，但是华为的电驱动业务，仅有电机和BMS系统，而且道行尚浅，产品种类和技术积累不如博世。

但是华为电驱的集成化和智能化做的比博世好。华为七合一系统的集成程度是博世无法做到的，智能化上，电驱动能实现云控制，这在行业内都是创新举动，目前博世没有相关产品。

Ø 自动驾驶业务

自动驾驶硬件又是一片红海。博世苏州在国内已经布局多年，有众多的客户资源以及量产经验。产品线上，博世从雷达到摄像头，超声波传感器，传感器芯片都有，但是华为仅有雷达和摄像头产品，且没有太多量产经验。

但是华为在自动驾驶处理器上优于博世，有自己的鸿蒙操作系统，而博世没有自己的操作系统；在自动驾驶方案上，两者难分伯仲，因为没有成熟的产品能够证明彼此实力。

Ø 智能座舱和车联网

智能座舱与车联网产品上，两者差距不大。产品线上，T-BOX，车机系统，HUD，以及显示屏技术两者都有。但是华为基于在通讯领域的多年经验，在“智能化”上做的比博世好，尤其是在智能语音和操作系统方面优于博世。

Ø 研发能力

说完了硬实力，说到软实力。双方在软件工程师数量，量产经验，客户数量上差距明显。

论软件团队实力，华为在博世之上，华为汽车BU有2000多软件工程师，且互联网工程师能力普遍比汽车行业软件工程师强，博世还需要加大在研发能力的投入上。

量产经验和客户数量上，博世又是华为无法超越的大山。作为新人，华为客户虽然慢慢再增多，但是量产经验还太少，处于萌芽期。但是博世就不一样了，多年的客户资源积累，量产经验，相比之下更容易取得客户的认可与信赖。

综合以上分析，华为在汽车行业入局较晚，有很多方面还需要追赶，但是凭借ICT通讯领域的积累和技术口碑，也慢慢在某些方面已经形成了优势。智能电动车时代下，谁将是第一供应商，拭目以待。

本文首发于汽车之家，本人原创，转载请联系本人。