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的分层设计要从如下几个角度切入。架构，方法学，应用接口。详细了解的话可以看这个文件
架构层面： 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 评论文章
中间件有了，只是我们和硬件完成了剥离，但在和其他模块的交互机制上仍然存在问题，这里先要聊下单播，组播和广播三个概念。
这三个概念，原本来源于计算机以太网通讯（就如软件定义汽车，现在车辆也用了这个概念）
单播(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升级等。
只要你有手机基本都经历过这种升级。之前说软件定义汽车就是要把汽车做的和手机一样，什么意思可以看我这个回答。
核心是这个图，画的潦草了一些，这里面橙色画的都是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 评论回答
传感器攻防战-一文汇总自动驾驶的那些传感器
横看成岭侧成峰，远近高低各不同，不识庐山真面目，只缘身在此山中。
用苏轼的《题西林壁》最能形象的描述自动驾驶的那些事。从技术工程师，到启动辅助驾驶的客户爸爸，再到高校政府。从学科体系，量产实践，司机感受再到道德法律，从多个方面切入自动驾驶话题都有一番不同的光景。这也是自动驾驶作为一个边缘学科与行业独具魅力的地方。
做传感器攻防战这个系列，初衷是说，对自动驾驶传感器的系统理解，是切入自动驾驶的一个不错的位置，由这个点开始纲举目张，我们能够较为简单的去理解整个自动驾驶的全貌。也尽可能促使，不陷入单个小山里，而忽略了庐山的真面目。
我的回答里很多会连接一些我相关联的回答，回答之间的跳跃，除了必要的补充，有时也是换一个角度看同一个问题，看远近高低才能呈现不同的风貌，对理解一个跨界的话题来说是有帮助的。
更新这个系列，源于下面这个回答，目前也已经更新这个回答的部分链接，这个回答看上去更完整一些，嗯嗯。
这个回答里传感器的部分实际是由一张图串起来的。通过频率的分布，我们几乎可以看到自动驾驶，辅助驾驶甚至人工驾驶所存在的所有传感器，有些能测距，有些能接收可见光，有些能承载信息流。
由这张图扩展了几个关键传感器的内容，实际还有地图V2X后台体系，激光和超声波相机还有些内容没有补充完，可以做的内容非常多，根据行业新的信息我会持续增加，并替换原来可能过时的内容。
戚继光针对倭寇摆出的鸳鸯陈，不知道为什么和传感器布置也有点像，兵种配合相互支援，只是应对的是不确认的环境而已。
想想很有意思，每种传感器都有短板，因此相互配合就非常重要，而鸳鸯阵的布置和自动驾驶有思路上的共同点。（上面这个图是看着有点像哈）
惯导居中“指挥”负责支援其他所有传感器（激光，视觉，GPS等），为他们提供感知间隙和失效过程中的空间位置偏移量（车转了多少度，走了多少米）
殷玮：传感器攻防战-惯导IMU97 赞同 · 10 评论文章
GPS居中负责支援所有信息类传感器（地图/V2X等），为这些信息类传感器提供必需的绝对定位信号，从而获得具体的信息，并和惯导组成稳定的“中军”
咋么看，咋么觉得两张图很像，是不是天下很多思路都很相似
地图和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 车规功能安全管理认证，这意味着华为相关产品可以满足汽车行业的高安全和高可靠需求。
在智能驾驶硬件部分，华为在武汉有一个光电技术研究中心，目标是短期内开发出100线的激光雷达，未来有望将激光雷达的价格降低到100-200美元；同时华为在射频领域有深厚底蕴，在毫米波雷达上也有望突破博世，大陆，海拉目前形成的垄断。
智能座舱解决方案
华为智能座舱的核心卖点在于鸿蒙车机OS软件平台和智能硬件平台。
鸿蒙操作系统OS主要面向车机应用，共包括语音，音效，视觉，AI等7大核心功能。OS接口支持3屏显示，7摄像头输入。华为智能座舱融合了出游，通勤等出行场景，拥有多项交互功能如人脸识别，信号灯提示，AR抬头显示等，可实现手机和车机的无缝对接，在未来，华为将为车企提供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云服务。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Go语言工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Go语言全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Golang知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Go）
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
3ed42.jpeg)华为七合一电驱
其中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云服务。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Go语言工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Go语言全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
[外链图片转存中…(img-jgyVwnT6-1713030291398)]
[外链图片转存中…(img-BgAcG9fl-1713030291399)]
[外链图片转存中…(img-vvhJ1C6o-1713030291399)]
[外链图片转存中…(img-ttEb2GFl-1713030291400)]
[外链图片转存中…(img-WamSElBj-1713030291400)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Golang知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Go）
[外链图片转存中…(img-EWqcy390-1713030291401)]
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！