软件定义汽车(Software Defined Vehicles, SDV)，软件改变着汽车的DNA，毫无疑问，软件对于汽车的重要性不言而喻，从2016年开始，自动驾驶的大潮来临之际，软件定义汽车已经作为一个趋势和方向，在汽车技术行业，包括工程师中讨论交流，硬件，软件，自动驾驶，汽车的未来在哪里？本文作者从自己的项目经历，所学所看，从不同的视角和角度给大家分享下软件定义汽车的一种解读，供大家学习参考！|| 作者：Leo Huang|| 首发文章来源：简书|| 作者简书链接：https://www.jianshu.com/u/1fbf94b14980|| 文章已获作者授权发布，版权归作者所有，仅供学习参考||  本合集共计18000字左右，需要阅读时间30分钟

合集目录1. 软件定义汽车1—概述2. 软件定义汽车2—面向服务的架构设计

3. 软件定义汽车3—SOA 基础软件框架与参考实现

4. 软件究竟如何定义汽车4-行业现状

5. 软件定义汽车5-中央计算单元架构01

引言作为一个技术的爱好者，搞算法，玩芯片，攒系统，并不只是工作，也是自己所追求的很重要的部分。写这个系列，是为了梳理这几年的所学、所思、所想，从而形成一个完整的知识体系，也供大家参考。这是一个横向跨度很大的新领域，大家都还在探索，水平有限，难免疏漏，不对之处请大家指正，也欢迎各领域的专家参与讨论。

由于自身电子设计和机器视觉的背景，早期的项目经历，让我涉猎了各领域的技术，包括电子设计、嵌入式软件、互联网全栈、移动端 app、操作系统、渲染引擎、内核驱动、工业控制现场总线等，每一个部分都不敢说有多么精通，但都经历过实际的项目。对车这个领域，并不是专业出身，之前了解并不多，但为了能理解一帮传统汽车人在想什么，也是恶补了博世系列的十几本关于车辆工程、汽车电子、电子电气架构、动力系统等方面的书。多领域的涉猎也给这个系列的主题，提供了不同的视角。

一、互联网与传统汽车人的碰撞在这个领域探索了几年，一个感悟就是，百年汽车工业，任何人也不要妄谈颠覆，但是也绝对不能拒绝进化。汽车界一直都有所谓的“传统派”与“互联网派”之间的话题争论。传统派与互联网派都有自己的优点，但却是有明确的领域限制的，比如互联网所倡导的以用户为中心，持续打磨产品和服务的设计理念，对于传统汽车行业的确有非常大的帮助。但是对于过程中所惯用的敏捷开发，快速迭代，却并不能完全套用，至少是有一定前提的。敏捷开发的前提有两个，标准化的基础设施的支持，并且需要有良好的架构设计。

互联网领域，部署代码的主要有，电脑端、移动端、服务端。每个端操作系统、应用开发框架、开发工具都非常标准，但如果是一辆传统架构的汽车，有几十上百个 ECU，而且还来自于不同的供应商，系统集成的复杂度不是线性而是指数级别的增加，不得不有一套严苛的流程去规范整个开发流程。

二、从电子电气架构的演进看软件开发分工的变化电子电气架构EEA(Electrical/Electronic Architecture)，最先是由德尔福公司提出的。汽车作为一个复杂的电子系统，按照传统定义，可以划分为车身、底盘、动力、信息娱乐、辅助驾驶等几大子系统；每个子系统又由多个电控单元 (ECU)组成，这些ECU连接起来就形成了一个网络结构；EEA 的主要职责就是定义这些ECU之间的连接方式与网络拓扑结构。电子电气架构

2.1 传统的分布式的电子电气架构的问题网络结构复杂，形成信息孤岛，中央网关会是性能瓶颈

ECU冗余，算力浪费，且无法形成协同

ECU 由不同的供应商开发，框架无法复用，无法统一 OTA

外部开发者无法对 ECU 进行编程，无法由软件定义新的功能

无法进行硬件升级

2.2 不同架构主机厂扮演的角色基于传统分布式架构，主机厂只是架构的定义者，核心功能是由各个 ECU 完成，其软件开发工作主要是由 Tier1完成，主机厂只做集成的工作，这也是为什么大部分传统主机厂基本没有软件开发能力的根本原因，就靠 DRE搞定供应商就能集成一辆车，为什么还要花大量的成本养一个庞大的软件团队。

基于域控制器架构，属于过渡形态，DCU 减轻了中央网关的压力，也可以实现部分业务逻辑，但大部分业务还是由各 ECU 实现，主机厂可能会参与部分 DCU 的开发，但与 Tier1的整体分工无太大变化。

基于中央计算的架构，此时大部分 ECU 消失，各种传感器与执行器，被中央计算单元所支配，原本属于 Tier1的大部分策略层面的软件需要由主机厂去主导，需要一只专业的软件团队，或者定义某种规范，让 Tier1实现，最后以软件模块的方式集成进来，这需要一只高水平的软件架构团队。

2.3基于中央计算电子电气架构的优点算力集中到为少数几个中央单元，可以留有冗余便于后续软件功能升级

经过良好的平台化设计之后，硬件单元也可以升级，如特斯拉的 AP

该架构是软件定义汽车的硬件基础，并不是有了新的电子电气架构就能够实现软件定义汽车，这还只是万里长征第一步，还需要有一个经过良好架构设计的基础软件平台。

三、车载环境下的操作系统提到基础软件平台，很多人的第一反应就是要做一个操作系统，操作系统的确是非常关键的一个组件，但是打造一个基础软件平台绝对不是再造一个操作系统。

3.1操作系统的定义操作系统是一种管理计算机硬件与软件资源的计算机程序，大众所知道的其实都是很泛化的操作系统概念，常见的概念分为四个层次。

3.2内核分类

微内核的好处是小、稳定，可以实现 RTOS，但是如果所有服务都在用户态实现，其运行效率是会打折扣的。通常讲车载上 QNX 比 Linux 稳定，不是因为它技术有多先进，而是其技术架构决定的。

3.3选择操作系统的核心因素业务类型：

如果业务有实时性要求，必然需要使用 RTOS，比如航天军工用的比较多的 VxWorks，车载用的比较多的 QNX。

芯片类型：

使用什么操作系统，往往取决于选择的芯片支持什么，没有芯片厂商的支持，一个操作系统走不远。嵌入式领域是ARM 的天下，处理器类型也决定了使用的操作系统类型，Cortex-A/M/R 用于应用处理器、低功耗、实时处理三个方面。

系统生态：

面向C 端用户的操作系统，应用生态决定了生死。面向行业的操作系统，比如汽车仪表、自动驾驶系统、网关，C 端用户是无法感知到底用了什么操作系统，开发者的态度决定了使用什么系统，没有人愿意在一个工具、库都支持不全的系统上开发软件。

3.4车载场景的操作系统选择汽车上的绝大部分ECU 都是 AUTOSAR 的天下，有些就是简单的单片机，甚至都不用跑操作系统。剩下的需要操作系统主要是信息娱乐、自动驾驶、复杂网关、TBOX 等。娱乐系统，其核心是多媒体和互联网应用，主要关注应用生态和开发者生态，国内大部分都是Android，少部分AliOS，特斯拉用linux，所以娱乐这块儿国内做的更好，但这并不是他的核心竞争力。由于生态的问题，针对车载的娱乐系统去开发一套操作系统，没有实际意义，以车的体量，也撑不起这样一个生态。这一块儿跟着消费电子走就行了，任何鼓吹系统底层能力的行为，都是隔靴搔痒，没有搞清楚重点。自动驾驶，其核心是算法设计和数据积累，没有人会把算法的软件实现和操作系统绑死，其设计一定是跨平台的，有成熟稳定的 RTOS 即可，目前主流的有三种 RT-Linux、QNX、VxWorks。由于深度学习构建在开源软件的基础上，也需要生态，这也是linux 虽然不是硬实时系统，但依然在自动驾驶领域用的比较多的原因 。自动驾驶这块，倒是缺一个类似于 ROS 的能够跨平台的分布式开发框架  ，虽然ROS2进化许多，但是在低延时、功能安全、信息安全方面还有很多路要走，国外有家创业公司APEX.AI，正在基于ROS2分支，把它往车规级方向做。NVIDIA 构建了一整套的框架，做的非常不错，但是和自家芯片绑死，限制了其使用范围。网关以及以后的大吞吐的以太网交换机，虽然算力要求也高，但是任务相对单一，架构也很简单，现有系统就能满足，也没必要去开发一个针对网关的操作系统。TBOX由于主芯片来源单一，目前基本是都是 Linux。经过以上的分析，大家可以知道，目前根本就不是因为操作系统的短板限制了软件化的水平，车载架构的特殊性，决定了无法使用单一操作系统来实现所有功能，多个操作系统并存的局面还会持续很久。

四、 中央计算电子电气架构下的基础软件平台前面提到，新的电子电气架构是软件定义汽车的硬件基础，并不是有了新的电子电气架构就能够实现软件定义汽车，还需要有一个经过良好架构设计的基础软件平台。下面我们就来对这个问题进行重新定义。

4.1 问题描述在新的电子电气架构下，多个中央处理单元、多个传感器、执行器、交换机等，在以太网的连接下，组成了一个复杂的分布式系统 ，由于工作任务的不同，多个中央计算单元运行着不同的操作系统。

4.2 核心诉求“软件定义汽车“，其核心内涵就是，能够通过软件的方式，动态改变上述系统当中网络节点之间的聚合关系，从而产生新的业务功能，因此对软件平台的要求如下：既然是软件平台，就应该不依赖于特定操作系统、芯片、车型，因此硬件抽象是最先该考虑的事情。

能动态改变聚合关系，就要求网络中的节点之间的连接关系是可以运行时更改的，同时每个节点应该具备高内聚、低耦合的特性。

需要满足车载环境高可靠性、实时、安全性。搞互联网后端的或者 IT 系统的人，看到“软件定义汽车“的描述，第一反应可能是，这不是就是我们搞微服务架构的思路吗？

这就是我想说的第二点，互联网的开发流程虽然不能直接套用在车上，但是其在软件工程领域的实践经验对于解决车载软件领域的问题还是很有帮助的。看起来是汽车电子软件开发的门槛高，其实是因为封闭和从业人员少。当前的机遇就是，大家都想往这个方向走，但是也都是摸着石头过河，可以有机会将这些理论经验用于实践。前段时间梳理了一下，面向下一代智能汽车的关键技术，分为智能座舱、自动驾驶、与数字系统。今天讲的主要数字系统当中，我认为最重要的软件基础设施，基础软件平台，下一篇将重点阐述，面向服务的架构设计与车载软件相结合的一些思考， 以下思维导图仅供参考！next_EE智能座舱

以产品设计为驱动力，但目前同质化现象比较严重，主要以硬件差异为基础，只能利用先发优势，无法形成技术与产品壁垒！

基于用户画像，使用AI技术，构建具有情景感知能力的引擎，是智能座舱产生质变的前提，但技术上短期无法突破(行业普遍问题，不是车行业特有)。

多设备协同、多模态融合交互，是消费电子IOT场景下大家探索的方向，对于车载环境有很强的借鉴意义。自动驾驶

以算法与数据的积累为核心驱动力，可以在技术上形成壁垒，但是需要巨额的研发投入，能否快速落地主要受制于数字系统架构。

短期来讲大家可能都差不多，但是积累到一定时间，后发玩家可能就再也追不上了。数字系统

以架构设计与资源整合为核心驱动力，其包含了传统意义上的电子电气架构，但需要横向整合多个软硬件架构部门，才能定义完整的系统架构。

是否采用新架构从根本上决定了，智能座舱与自动驾驶究竟能走多快走多远。良好的数字系统架构，能够屏蔽底层车型平台的差异，多个车型共用一套基础软硬件平台，能够缩减开发资源，一套架构持续５年，可以留出充足的资源研发下一代。02引  言上一篇文章主要介绍了电子电气架构、车载操作系统、基础软件平台等之间的关系，以及软件定义汽车的基本概念。本篇将继续深入，重点阐述三个问题：智能电动汽车软件范畴

软件+硬件升级的基础

面向服务的软件架构设计

一、智能电动汽车软件范畴按照新能源汽车的特点以及中央计算电子电气架构的发展趋势，可以按照以下三个类别，对智能汽车软件进行分类：动力与底盘控制器、车身控制器、中央计算单元。智能电动汽车软件分类动力与底盘控制器底盘类的功能，包括电子转向(EPS)、电子驻车(EPB)、车身稳定(ESP)、集成动态制动(IDB)等等，都是牢牢的掌握在了一线Tier手里，这部分软件都是和机械零部件绑定在一起的，在其整个生命周期内不会发生功能的改变(可能会重新标定新的参数)，实现的是车辆运行最基本的、有最高功能安全等级要求的、微秒级时延的功能。所以即使是在集中式的电子电气架构下，未来很长一段时间，这部分功能都会以独立ECU的方式存在，遵守Classic AutoSAR标准进行开发。在“动力与底盘”控制器中，整车厂唯一可以做并且非常有必要的是，提供一个底盘域的适配层，为中央计算单元提供标准的线控服务，这样以来，中央计算单元就不用单独和各个底盘ECU通信(不同车型可能使用了不同Tier1的产品)，可以做到中央计算单元和车型平台解耦。动力类包含了新能源三大核心技术，整车控制器(VCU)、电机控制器(MCU)和电池管理系统(BMS)，其中VCU通过采集油门踏板、挡位、刹车踏板等信号来判断驾驶员的驾驶意图；通过监测车辆状态(车速、温度等)信息，向动力系统、动力电池系统发送车辆的运行状态控制指令。BMS负责估测动力电池组的荷电状态 SOC，即电池剩余电量，保证SOC维持在合理的范围内，同时监测电池充放电过程中的温度、电流、电压等，保持整组电池运行的可靠性和高效性。MCU系统根据数学模型，采集位置、电流信号，对IGBT进行通断控制，形成交变磁场，从而控制电机按目标进行运转。这三大部件对整车性能有着重要影响。越来越多的主机厂选择自己进行开发，也就有了往集成化方向发展的基础，可以逐步将功能迁移到“底盘与动力”控制器当中去。车身控制器传统也叫BCM，车身控制相关的功能包括，车门、车窗、天窗、雨刮、照明、空调、空气净化、无钥匙进入等等，整车厂对这部分具有很高的决定权，现存的绝大部分ECU上的功能都可以搬到车身控制器上去，按照开关、传感器、执行器的维度对原有ECU的功能进行分解，主机厂可以自己开发，也可以要求Tier1按照规范提供软件模块，由主机厂进行集成。中央计算单元中央计算单元的集成的三个重要模块分别是自动驾驶、智能座舱、通信单元。为什么把这三块放在一起，下一章会详细介绍，本节重点介绍其内容。自动驾驶，软件上具体的要做的事情，上一篇有过介绍，其核心是算法和数据的积累，稍微有点实力的主机厂都不会放弃自主研发，因为一旦掉队，短时间追不上来，也将彻底沦为硬件的代工厂，这是一个需要长期高投入的领域，在这个领域当中，主机厂、算法商、Tier1等各自的分工，也都还在探索当中。传感器与芯片算力，是发展中的主要制约因素。智能座舱，各个主机厂都在做，其技术和生态是消费电子在车场景的延展，一般会选择一家互联网公司合作，其核心还是围绕了人机交互展开，探索人与设备之间的关系，目前最主要的两大交互方式就是触屏+语音，对整车硬件的智能化的水平有很高的要求，但是车载硬件算力的滞后特性，导致功能体验不如消费电子。通信单元，也叫TBOX，是车与外界联系的枢纽，目前主要实现的功能，如远程车控、远程诊断、整车OTA、国地标数据采集等等，与车的联系非常紧密，主机厂一般都会自己开发上面的应用软件。其发展和通信标准的强相关，比如4G到5G的切换，未来技术上影响较大的因素是V2X，其发展会改变目前的软硬件架构。

二、软件+硬件皆可升级的基础软件OTA的能力，各家主机厂目前都已经具备了，相比于传统的汽车，软件OTA在一定周期上给汽车注入了新的活力，但依然会碰到算力的天花板。汽车的机械零部件，出厂之后，其功能整个生命周期都不会发生变化，但是中央计算单元，其发展始终跟随最新的ICT技术，在车的生命周期当中，算法、芯片、通信标准等会不断的更迭换代，车的生命周期都在5年以上，但相关的ICT技术，基本2年就会有一个大变样。用户不可能像换手机去一样去换汽车，既然不能换车，为什么不能让用户可以升级中央计算单元呢？升级中央计算单元硬件，特斯拉已经在这么做了！为什么传统主机厂以前在这方面不作为呢？还是卖硬件的老思维，一次性买卖，没有升级零部件的动力！

喜欢搞各种花式车型，每个车型为了体现差异，还要改改硬件、比如多装一块屏，改改屏幕分辨率，竖屏改横屏，等等！

底层车型电子电气架构还不统一，换一家厂商的零部件，信号就得重新适配！

对智能化不重视，软件能力差，无能力架构跨平台的软件基础设施以上几个原因，导致了软硬件无法形成平台化，原本羸弱的资源，全部耗散在了无限的车型适配工作当中，根本没有资源提前去研发下一代平台，如此产生恶性循环。写这段的时候，我还是有点激动，曾经加班加点，就是为了把同样的工作适配到十多款车型，毕竟也是为此耗散过青春！Tier1的朋友们倒是很开心，反正只要给钱，主机厂愿意改，他们就愿意接！不仅要在用户看得到的功能上下功夫，还要在软件的工程能力上下功夫，重视架构设计，否则一旦历史的包袱积累到一定程度，连重构的勇气都会丧失！作为中国高科技公司的代表，连任正非都喊出了华为要加大投入，提高软件能力的口号！如何能够做到中央计算单元的软硬皆可升级，才是真正考验软硬件架构能力的课题，特斯拉已经开了个好头，就看接下来追上去的是谁。动力与底盘控制器、车身控制器，其核心软硬件设计目标，是要为中央计算单元提供良好的服务接口，让中央计算单元既能够灵活调用，同时也保持松耦合关系，终极目标是实现软硬件皆可升级。

三、面向服务的架构设计在传统的离散架构下，车内的ECU通过总线相互通信，但是它们之间的信号收发关系和路由信息都是静态的，是在编译阶段写死的。各个ECU会周期性的发出各种信号，如果需要在另外一个子网当中使用，还需要网关进行转发，出于负载的考虑，网关通常不会把所有信号都转发，如果预先定义功能中，不包含某个信号，而后续又要使用，除了修改业务所在单元之外，还需要对网关的配置进行修改。如果车辆上市后，想在某个控制器上新增功能，可以通过OTA更新该控制器的软件，但是这个功能需要的其他控制器的信号怎么解决呢？当然，也可以把所依赖的控制器都OTA一遍，但这个工作量与同时OTA的控制器的数量是指数关系，新架构上升级一个控制器，一个月就能解决的事情，在老的架构上可能需要一年。面向服务的架构(Service-Oriented Architecture，SOA)，是一种架构设计思想，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。SOA在互联网IT中有很多应用案例，和微服务的架构有相似的地方，具体可以参考SOA和微服务架构的区别。简单来说，SOA就是要求各个控制器，把自己的能力，以服务的方式提供出来，以此来构建一个与车型、芯片、操作系统无关的灵活可变的平台系统。服务内高内聚，功能完整，可复用

服务间低耦合，无依赖

服务通信接口标准化，不依赖于平台实现。下面举个例子来说明，在中央计算电子电气架构下，以以太网为通信方式，把各个控制器提供的功能按服务的维度进行拆解(以下只是示意，主要为了讲清楚原理，服务的分类、拆解、分层，是一个架构设计的细活儿，是一个系统性的工作)。面向服务的架构设计举例上面这张图，软件上的分层看起好像和传统软件的架构也没太大区别，其实这里面最关键还是服务间的连接关系，其核心是需要SOA框架软件的实现一套服务管理的框架，类似与IT领域所说的 UDDI(Universal DescriptionDiscovery and Integration，统一描述、发现和集成)，提供服务发布、查找和定位的方法。在这个框架下，服务节点可以动态加入，并且按照统一标准实现的所有服务都是对等的，服务之间可以动态的建立订阅/发布的关系，且相互之间以一种中立的服务描述语言为契约，是一种松耦合的关系。服务可以分为三类，原子服务、组合服务、流程服务，原子服务提供的是最基本的功能，比如获取传感器的数据、升降车窗指令；组合服务是利用多个原子服务，实现了部分判断逻辑，比如升降车窗并不是任何条件下都能执行，还需其他条件去综合判断；流程服务，是根据业务功能定义的服务，比如产品上定义一个抽烟模式，需要同时打开车窗、天窗，并播放车主收藏的音乐，这就需要调用多个组合服务去实现。原子服务，一般和硬件功能有关，硬件功能决定了原子服务的范围；组合服务，可以认为和某种策略和控制逻辑相关，比如实现一种新的驾驶模式；流程服务，可以认为是和特定场景下的产品功能。在SOA的软件框架下，“软件定义汽车”就变成了，在一个完备的原子服务集合当中，通过定义新的组合服务与流程服务，去实现新的产品功能。而在硬件可升级的前提下，又可以通过硬件升级，去拓展原子服务的功能范围。比如，换了带V2X的中央计算单元，就可以新增V2X相关的原子服务，然后定义一个新的流程服务，如，基于V2X的紧急刹车。当然新的架构，也一定会带来新的挑战:架构设计的挑战， 比如上面提到的服务的拆解、分类、分层，这类工作往往具有一定的灵活性，需要不断地去摸索和总结最佳实现。

功能安全的挑战，传统AutoSAR，功能静态部署，可以对每个分支流程，做危害分析，而SOA功能可以动态部署，无法预先做到每个场景都覆盖到。

信息安全的挑战，传统的离散系统，造成信息孤岛的同时，也无形之中构建了一道物理防火墙，现在服务都变成了对等节点，就需要一套完整的权限控制解决方案。结 语本篇主要对智能汽车软件的范围、软硬件升级、SOA的内涵进行了介绍，下一篇将重点介绍，SOA实现的基础；对常见的技术概念，车载以太网、SOME/IP、DDS、Adaptive AutoSAR、ROS2 等，梳理各自所处的技术层次与要解决的问题，阐述其与SOA的关系。03引 言上一篇文章对智能汽车软件的范围、软硬件升级、SOA的内涵进行了介绍。本篇将围绕 SOA的实现细节，重点阐述以下问题：SOA 基础软件框架

SOA 参考实现

SOA 实现所需相关技术

一、SOA 基础软件框架上一篇中，介绍了面向服务的软件架构设计SOA，但它只是一架构种设计思想，本身并不是一个软件模块。工程中需要一个基础软件框架去实现其架构设计思想，下图中的 SOA Framework 就是我所说的基础软件框架。SOA Framework上图中所表示的就是一个典型的中央计算电子电气架构，几十个 ECU 的功能，集中到少数计算单元上，大部分 ECU 消失了，但是由于底盘域的特殊性，依然保留了部分 ECU 的功能。几大控制器，选用的都是高性能的 SOC(画3个只是示意)，由于工作任务的不同，选用了不同的操作系统。SOA Framework 是这个分布式软硬件系统运行的关键，具有以下特点：它是一个操作系统中间件

运行在不同的OS 内核之上，可以跨平台。

除了基于以太网，最好还能兼容传统 AutoSAR

需要为上层应用提供良好的开发接口。

需要与多个 SOC 上的 SOA Framework 进行分布式协同。SOA Framework 架构SOA Framework 整体架构如上图所示，其主要功能如下：本地服务、远程服务(运行在另外一个 SOC 上的服务)，相互之间以统一的接口描述语言IDL为契约。IDL 是一种中立的语言，与 OS 以及开发语言无关。

通过Service Development Framework，为开发者提供服务开发的基本框架。

Service Manager 管理本地服务，并负责与远端的 Service Manager 进行同步。

Policy Manager 负责控制各个服务间的访问权限。

Network Manager 负责网络通信管理，有可能会使用不同的通信协议。

Startup Manager 定义服务间的依赖关系与启动顺序。

Update Manager 负责服务的更新与升级。

OS Abstraction Layer 负责抽象各个 OS 的差异。

实际实现过程中，还需要很多其他服务作为支撑，比如持久化、加解密等，以上架构图，只是为大家讲明原理。在这个基础框架之上开发的服务，相互之间都是松耦合关系，通过我们上一篇中讲的，重新定义新的组合服务和流程服务，就能产生新的软件功能。不同芯片的差异会在操作系统层面屏蔽掉，而基础软件框架又屏蔽了操作系统的差异，在此架构下，即使更换新的 SOC，软件上的改动也会很小，也为硬件可升级也提供了软件基础。

二、SOA 参考实现ROS与Adaptive AutoSAR 都是遵循 SOA 架构设计思想的一种操作系统中间件。为什么放在一起讲，是因为他们都有可能发展成为一种适用于车载环境的分布式通信与计算框架。ROS(Robot Operating System)主要目标是为机器人研究和开发提供代码复用的支持。是一个分布式的进程(也就是“节点”)框架，这些进程被封装在易于被分享和发布的程序包和功能包中。ROS 之前更多的用于学术研究，随着这几年人工智能和自动驾驶的发展，在很多自动驾驶的原型系统中都能够看到 ROS 的身影，百度 Apollo 最初也是使用了 ROS。在发展过程中，ROS原先架构设计上的缺陷也慢慢暴露出来，为了解决这些问题，2017年，采用新架构的 ROS2 问世。ROS2 最大的改变是，取消Master中央节点，实现节点的分布式发现，发布/订阅，请求/响应通；底层基于DDS通信机制，支持多操作系统，包括Linux、windows、Mac、RTOS。要把 ROS2改造的完全适合车载，还有不少工作要做，之前提到的 APEX.AI公司，就是在做这个事情。Classic AutoSAR 是开发 ECU 的主要标准 ，相关的介绍网上很多，就不多做介绍，Adaptive AutoSAR  2017年才发布第一个release 草案，主要用于高性能 SOC，运行在兼容 POSIX的操作系统之上，其也运用了 SOA 的架构设计思想。从Adaptive AutoSAR 和 ROS 当中，能够看到德系与美系架构设计思想之间鲜明的差别。我的第一感受是，美系架构设计更加简洁、灵活，追求开源。而德国人喜欢把简单的问题复杂化，喜欢过度设计，搞很深的抽象层次，喜欢搞代码生成，喜欢强绑定 IDE，这可能与他们工程师思维的严谨性有关系，总之搞得看起来门槛特别高，相关的公司还可以卖标准，卖工具，赚的盆满钵满。传统 ECU 开发中，Classic AutoSAR 依然会占主导地位， 德系公司是毫无疑问的主导者，但是我个人并不看好 Adaptive AutoSAR 的发展，主要有以下几点:其标准的推进事实上已经落后于行业应用。

在自动驾驶的发展方面，中美是主导，德国已经无法实现他在传统汽车领域的霸主地位。

开源软件，成就了人工智能、自动驾驶相关行业的繁荣，德系软件商这种设置高门槛，通过标准挣钱的做法，很难继续下去，一套基础软件收费超过千万，没实力的会选择开源，有实力的也会自己去开发，大家顶多借鉴一下其设计思想。

三、DDS 与 SOME/IPDDS(Data Distribution Service) 与SOME/IP(Scalable service-Oriented MiddlewarE over IP)，都是基于TCP/IP 实现的一种应用层通信协议，主要实现以下功能：数据序列化

服务发现

数据的发布订阅机制DDS 主要用于工业互联网、军工等领域，车载领域也有一些使用，比如 Nvidia 的 Drive AV 平台，底层通信就是基于 DDS，也是 ROS2的底层通信协议。SOME/IP是随着 AutoSAR 发展起来的，目前已经被纳入进了 AutoSAR 的标准当中，是 Adaptive AutoSAR 的底层通信协议。DDS 与 SOME/IP两者功能大同小异，SOME/IP 与 AutoSAR 生态兼容良好，但是 DDS 功能更强大，比如能够实现 QoS(Quality of Service,服务质量，是网络的一种安全机制, 是用来解决网络延迟和阻塞等问题的)。在CAN总线中，通信过程是面向信号的，发送方周期性的发布信息，而不考虑接收者是否有需求。DDS与 SOME/IP则不同，收发双方是一种订阅/发布机制，它是在接收方有需求的时候才发送，优点在于总线上不会出现不必要的数据，从而降低负载。DDS 与 SOME/IP的实现，是以以太网为基础的，为什么要用车载以太网，除了大家都知道的传输带宽问题，其实从软件的角度来讲，以太网最大的好处，在于它的网络模型层次比CAN要全，能够在此基础上定义比较复杂的应用层协议。结 语本篇主要对SOA 软件框架进行了介绍，对常见的技术概念，车载以太网、SOME/IP、DDS、Adaptive AutoSAR、ROS2 等，梳理各自所处的技术层次与要解决的问题，阐述其与SOA的关系，下一篇主要聊聊一些非技术性的问题，比如行业现状，落地中实际会碰到的困难等。04引 言思绪乱飞导致失眠，索性打开电脑记录了下来，前几篇主要写技术。本篇主要介绍一下行业现状，介绍技术和数据是相对客观的，但是谈观点就会有我自己的主观意识在里面，所以这方面仅供大家参考，主要包含以下内容:车企在软件方面投入

传统车企之殇

车企突围之道

最后的实力玩家车企在软件方面的投入根据中国人才研究会的报告，全中国，所有的车厂、 Tier1、车联网公司加起来，其软件开发人员数量，不到2万人，但是互联网公司中，仅阿里巴巴一家就用有超过3W的程序员。(2W 我估算还是比较准确的，国内最大的两家，一家国企，一家民企，软件人员约在1200人左右。供应商中的第一梯队软件人员平均下来也不超过500。)从相对数量上，也能得到一个比较有意思的结果：

上汽集团，员工超过10万，其软件中心规划1200人 ，约占1.2%。

大众集团，员工超过50万，软件开发人员约5000人，约占1%。

新势力中威马、蔚来、小鹏，软件开发人员都略低于10%。

特斯拉数据我无处考证，但从其前中国区负责人表述“特斯拉60%的工程师都在做软件”，估计其软件开发人员占比应该超过20%(知道的朋友欢迎提供准确数据)。传统车企之殇大家普遍都认为传统车厂，在软件投入、智能化方面行动缓慢，为什么会这样，有很多种解释，大部分都是从人的角度或者从组织的角度去阐述这个问题，今天我想从另一个维度为大家提供一个新的视角。一家商业公司为什么会存在? 最根本的动力还是为了追求利润，企业所有的行为动机都是为了追求利润的最大化。那么传统车企又是靠什么盈利呢？概括起来就一句话，把供应商的零部件组装起来卖出去，赚成品和零部件之间的差价，至于其他的业务，如汽车金融，都是寄生在这个逻辑之上。在这样一个商业模式之上，整车厂是高度依赖供应链的，燃油车时代还有三大件的差异，到了电动化时代，硬件上几乎全靠供应商，所以只要供应链上有的东西，所有车厂都可以上。这种状况，其实和目前的 手机厂商非常相似。在硬件同质化的情况下，各家如何形成产品上的差异化呢？无非也就那么几种手段。对手机来讲，就是外观、屏幕、摄像头、电池、系统 UI、配置 等等。对车厂来讲也是类似的，造型、内饰、配置、电机、电池等。相比于手机，车的零配件就更多，所以在配置上可以玩的空间就更大，各家传统车企这方面都是专家，各种花式车型层出不穷。在这样一种模式下，为了追求毛利润的最大化，手机厂和主机厂能做些什么呢？其实也就一件事情，供应链优化，换句话也叫，压榨供应商。这种模式带来的结果就是，所有的传统车企，其毛利润都在15%左右，做的最好的丰田也就18%，而特斯拉已经达到了25%，其model3甚至能够到30%以上；大部分Android 手机厂商，其毛利润也都只有15%左右，而苹果毛利润高达38%，所以有个说法，手机产业链上60%的利润都让苹果拿走了。对于传统车厂的做派，之前我也是有些看法，可是当我从这个新的角度重新去审视这些问题的时候，我一下就释怀了！当前的局面，是以硬件差价为盈利模式的必然会导致的结果，不管是员工的观点，还是其组织的安排，还是其与供应商的分工，在这种模式下都是市场选择的结果。只有硬件才能产生价值，这种模式和观念，是百年汽车工业演化的结果，要改变谈何容易，能够领导传统企业完成自我革新，不被外部潮流所摧毁的领导者，也会成为这个时代的传奇。所谓的智能科技不是光靠堆硬件配置，硬件需要软件来驱动，加大软件方面的投入，是提高汽车智能化水平的唯一出路，换句话说其实就是，智能是靠代码堆出来的。从用户的角度来讲，智能科技，能够吸引更多客户。从资本的角度讲，智能科技，能够形成高估值，被定位成了传统就只能有10-20倍的估值，一旦有了智能科技属性，享受50倍以上估值，完全不是什么问题。从企业经营的角度讲，智能化带来的高品牌溢价和附加值，能够提高企业的利润率水平。传统车企的突围之道我一直认为，改变当前局面，技术只是辅助手段，更多的因素都是非技术层面的事情，总结下来，以下挑战是必须面对：明确战略方向

传统车企，在软件投入方面欠下了太多债了，庞大的系统工程，需要长期持续且坚决的投入，才能产生变化。战略上的飘忽不定，是没法做出实际有价值的东西，我自己观察，这波趋势起来，很多企业也只是跟风，那些坚持投入做正向研发的企业，最终一定也会获得市场与人才的双丰收。

重塑组织架构

传统车企，在现有的以制造为主的体系架构下，很难完成软件能力建设上的突围。最现实的问题就是，以制造业的薪资体系很难吸引高质量的软件人才，即使是薪资水平没问题，一旦被打上的传统标签，很多人就会敬而远之。

统一顶层设计

构建下一代智能汽车的软硬件平台，是一个需要跨领域专家紧密合作的工作，需要电子电气架构、汽车电子软件架构、自动驾驶与智能座舱系统架构等，多个架构部门联合工作，所以架构上必须高度统一。

融合开发流程

GVDP是整车开发所遵守的流程，它定义了每个阶段该做的事情和交付物，这是百年汽车工业智慧的结晶，传统的汽车电子软件开发遵循A-SPICE，两者的冲突倒是不大，但是那些需要频繁OTA的软件，比如座舱相关的软件，其开发流程其实更接近敏捷开发，在实际项目中，软件部门经常会和整车集成部门在这方面产生冲突，大家对各阶段的交付物和交付标准理解不一致。整车部门希望你交付的时候就是全功能，而软件此时还在开发过程中，交付的功能不仅不全还会有Bug。整车的开发周期是以年为单位，而软件的开发目前是以月为单位，如果是涉及车辆底层的软件，软件与架构部门介入的时间也会发生变化。这方面，还没有形成行业标准，大家都是摸着石头过河，如何处理不同开发流程之间的冲突，是设计开发流程上的一大挑战。

重新定义分工

在新的软硬件平台之下，前面几个问题都是车厂自己需要解决的事情，外部因素当中，最大的挑战就是，如何重新划分与硬件Tier1的分工，可能大部分车厂都会倒在这个问题前面，体量太小，根本就没有平等对话的权利。考虑这个因素，小车厂要么会消失，要么就等整个产业链被彻底重塑之后再跟进。最后的玩家是谁？长期高投入，需要整合供应商资源，需要强大软硬件整合能力，三个门槛基本上把大部分玩家都挡在了门外。所以实力玩家基本可以锁定，一类是像大众这样的国际一线主机厂 ，一类是像博世这样的国际一线 tier1  ，他们属于传统巨头的转型  ，还有一类是实力新玩家。特斯拉目前毫无疑问是标杆，马斯克自带科技光环，在电动车领域几乎是吊打这些传统巨头，那些看衰特斯拉的几乎都是从各个维度被打脸，那些叫嚣超越特斯拉的，也要从技术上重新审视自己。底层架构和自动驾驶是特斯拉的强项，但是特斯拉也有自己的短板，随着自动驾驶慢慢成熟之后，车也在成为一款大型的可移动的智能硬件。作为车，特斯拉非常优秀，但作为智能硬件，却略显不足，因为它依然是一个独立存在的实体!为什么这么说呢？车以后作为一个移动的智能空间，也是人生活空间的一种延展，换句话说，就是会成为消费电子场景的延展，而目前消费电子正在从单一的设备交互，向多设备协同的方向发展。个人所拥有的所有智能设备，应该是智能一体化的。虽然目前也有一些尝试，比如用apple watch开车门，车家iot设备互联，hi-car手机车机互联，车机语音和家里语音终端互联，手机蓝牙钥匙等，体验上都非常割裂，基本每个功能都依赖于特定app，不是操作复杂就是使用场景受限。前几年经常提的所谓云端账号打通，一定程度上能够解决数据交互的问题，但体验割裂的问题无法从根本上解决。从技术上讲 就是要求 车脑 家庭智能中枢 移动设备智能中枢 是同一个智能实体 多家的产品没法放在一起玩! 所以除了软件生态，还需要有一个完善的硬件生态! 多设备对用户的粘性也会比单一设备大很多，这就是为什么apple的很多用户，是android阵营怎么也抢不过去的原因。所以，在汽车领域还有另外一个强大的隐形玩家就是苹果，从各种专利信息，挖人的动作，可以看出，苹果一直都没有放弃造车，他几乎拥有所有的关键性要素，操作系统、芯片、算法、硬件生态、软件生态、软硬件整合能力、人机交互设计、雄厚的资金、强大的供应链支配能力等等。图形界面、ipod、mac、智能手机、平板、手表、无线耳机，苹果是人机交互领域当之无愧的领导者，车载人机交互，各项技术都已经趋于成熟，目前的玩家都缺乏颠覆性的软硬件整合能力，行业正处在一个临界点，苹果憋的这个大招什么时候释放，我们拭目以待!从这样一个逻辑来看，只要苹果放出了这个大招，就证明了消费电子巨头向汽车领域延展的可行性，那么国内的华为就一定会跟进，事实上在消费电子领域，华为已经在向苹果靠近，打造软硬一体的生态系统了!  这样一来，华为目前对外宣称的不造车就不攻自破，不是不造只是时候未到!从另外一个维度来看，华为也很有可能慢慢被“逼”上造车的路，其汽车BU定位于汽车ICT领域的增量供应商，从软件定义汽车的角度来讲，主机厂应该要成为主导，但是以国内目前的进展，很多新的东西可能找不到车能上，就算不直接造车，内部也会按照自己对汽车的理解，打造一台基于新架构、新平台的汽车，否则太超前的东西这帮传统玩家可能根本没法配合玩! 局面可能类似于今天的半导体产业，由于产业链上的队友太弱，很多东西最后不得不自己去做!就像拍电视剧，最先出场的不一定是最牛逼的，大部分玩家可能都是起了个大早赶了个晚集，最后被真正的实力大玩家收割!正是因为这个行业目前投入的不足，在未来反而蕴藏了巨大的机会  ，虽然目前是汽车业的寒冬 ，但这个寒只是传统的寒，各大谋求突破的玩家依然在疯狂的招揽人才，在这种微妙的趋势当中 作为个体，定好自己的方向，找好自己位置 ，跟着潮流走就行了！梳理这些东西，从我个人的角度来讲，也是在从技术和行业两个维度锁定自己方向。结 语这篇都是我自己的个人的一些看法，不像讲技术那么客观，欢迎大家拍砖，也希望大家分享自己的看法！05引 言前几篇更多是从全局的视角阐述软件定义汽车，但写这个系列并不只是为了介绍软件架构，也不是为了给大家推销理念或普及概念，而是为了构建一张完整的全系统知识图谱，系统性的探讨在实现过程中的各种技术问题。按照我的想法，后续工作将按以下两个阶段进行：设计阶段

开源实施阶段第一阶段通过系列文章以及和大家的交流讨论，梳理要解决的关键问题，确定解决这些问题的技术路径，设计关键组件的技术架构。第二阶段将着手搭建关键软件组件的代码框架。'Talk is cheap, show me the code' ，对我而言，架构设计不只是画几张图就完事了，搭建一个基础的代码框架，也是保证架构设计能够快速推进的有效手段之一。如果你是软件产品设计、架构设计、程序设计的高手，又对开源软件感兴趣，可以在后台留言，这种局面是有机会做点事情的，兴趣驱动无任何商业目的，欢迎各路geek参与讨论！在科技圈工作久了的人，估计也很难理解，为啥汽车行业会形成这种群雄割据的状态，汽车软件的封闭性，看似给这个行业构筑了壁垒，实际上也限制了整个行业生态的发展，开源软件造就了今天人工智能行业的繁荣，但一眼望去，整个汽车软件行业依然一片沉寂，都知道软件很重要，可是符合行业要求的人才从什么地方来呢？构建一个面向车载的全栈软件参考方案，思考并解决各个组件在车载环境下面对的挑战(实时可靠、功能安全、信息安全)，一方面为各方提供一些参考设计和思路，另一方面也为刚入门的行业初学者领领路，软件方面将重点围绕以下主题展开：车载RTOS系统

Hypervisor虚拟化

分布式通信框架

分布式服务开发框架

分布式计算框架中央计算单元的架构完整的数字系统架构，是软件定义汽车的技术基础，应该是由，电子电气架构+计算单元硬件架构+软件架构三部分组成。EEA 构型传统的整车部门也会有电子电气架构，其涵盖的内容很广，但是数字系统更多的关注通信与计算的部分，两者是一个互补的合作关系。在Domain向Zonal发展过程中就产生了一个分水岭，Domain之前传统的EEA部门就能完全应对，Zonal 之后由于新增了大量的软件开发工作，需要与软件团队高度合作。今天讨论的重点不是EEA架构，而是其中最关键的部分，中央计算单元，不管是按区域的架构，还是以后的纯中央计算平台，其硬件构型从根本上决定了软件架构的设计方向。中央计算单元构型中央计算单元可以分为以下三种形态：分离式

硬件隔离式

软件虚拟式分离式是指，将多个不同的芯片集成到一个中央计算单元上去，每个运行不同的操作系统，只是在形态上集中到了一起，各单元依然独立的完成各自任务，代表如特斯拉AP，奥迪zFAS等。硬件隔离式是指，在统一的计算平台上采用虚拟化方案，同时运行多个操作系统，但是各个系统依然在硬件上进行隔离，每个系统都有自己的专属硬件资源。软件虚拟式是指，在统一的计算平台上采用虚拟化方案，同时运行多个操作系统，每个操作系统所使用的硬件资源，由Hypervisor层动态调配，每个系统并没有专属的硬件资源。分离式最大的好处就是功能边界清晰，相比于传统的独立的BOX，只需要在电路设计上，把每个芯片放在不同的PCB板，然后将多块PCB叠加在一起。坏处就是，硬件资源浪费，每个芯片都需要一个最小系统，并且硬件上还没法拓展。硬件隔离式和软件虚拟式，都采用了虚拟化方案，唯一不同点在于硬件资源是否专属，如果是专属的，就意味着资源无法动态调配，容易产生资源浪费。虚拟化方案最大的好处是，硬件上的可拓展性，如果中央计算单元采用刀片式的设计结构，可以很方便的拓展计算单元的算力，而不用替换整个计算单元。谈到Hypervisor虚拟化，大家最大的顾虑就是稳定性，其实在中央计算单元中，只需要两个操作系统即可，用于自动驾驶、车控、网关的RTOS，以及用于娱乐的普通OS(如Android、Linux)。用于娱乐的OS完全可以通过虚拟机的方式运行，用于自动驾驶、车控、网关的RTOS，可以直接运行在Hypervisor层，这样在兼顾实时计算的要求的前提下也能获得丰富的娱乐系统功能。结 语前面几篇介绍了面向服务的架构设计SOA，但是SOA其实只是解决了软件定义汽车中的一个问题，即服务的开发、通信等问题，他只是整个技术栈当中的一环，而且也并不是解决这个问题的唯一途径。收到了一些专家的反馈，他们认为应该从更高的维度去阐释软件定义汽车，架构设计中，不仅要包含车载计算，还应考虑其与云端、边缘端等的关系，所以接下来将从底层的基础系统入手，逐步向上拓展，将这个分布式系统的范围进一步扩大。本篇只是开了个头，下一篇将重点探讨，Hypervisor虚拟化技术在基础系统架构中的应用。