引言
作为一个技术的爱好者，搞算法，玩芯片，攒系统，并不只是工作，也是自己所追求的很重要的部分。写这个系列，是为了梳理这几年的所学、所思、所想，从而形成一个完整的知识体系，也供大家参考。这是一个横向跨度很大的新领域，大家都还在探索，水平有限，难免疏漏，不对之处请大家指正，也欢迎各领域的专家参与讨论。
由于自身电子设计和机器视觉的背景，早期的项目经历，让我涉猎了各领域的技术，包括电子设计、嵌入式软件、互联网全栈、移动端 app、操作系统、渲染引擎、内核驱动、工业控制现场总线等，每一个部分都不敢说有多么精通，但都经历过实际的项目。对车这个领域，并不是专业出身，之前了解并不多，但为了能理解一帮传统汽车人在想什么，也是恶补了博世系列的十几本关于车辆工程、汽车电子、电子电气架构、动力系统等方面的书。多领域的涉猎也给这个系列的主题，提供了不同的视角。
第一篇
一、互联网与传统汽车人的碰撞
在这个领域探索了几年，一个感悟就是，百年汽车工业，任何人也不要妄谈颠覆，但是也绝对不能拒绝进化。汽车界一直都有所谓的“传统派”与“互联网派”之间的话题争论。传统派与互联网派都有自己的优点，但却是有明确的领域限制的，比如互联网所倡导的以用户为中心，持续打磨产品和服务的设计理念，对于传统汽车行业的确有非常大的帮助。但是对于过程中所惯用的敏捷开发，快速迭代，却并不能完全套用，至少是有一定前提的。敏捷开发的前提有两个，标准化的基础设施的支持，并且需要有良好的架构设计。
互联网领域，部署代码的主要有，电脑端、移动端、服务端。每个端操作系统、应用开发框架、开发工具都非常标准，但如果是一辆传统架构的汽车，有几十上百个 ECU，而且还来自于不同的供应商，系统集成的复杂度不是线性而是指数级别的增加，不得不有一套严苛的流程去规范整个开发流程。
二、从电子电气架构的演进看软件开发分工的变化
电子电气架构EEA（Electrical/Electronic Architecture），最先是由德尔福公司提出的。汽车作为一个复杂的电子系统，按照传统定义，可以划分为车身、底盘、动力、信息娱乐、辅助驾驶等几大子系统；每个子系统又由多个电控单元 (ECU)组成，这些ECU连接起来就形成了一个网络结构；EEA 的主要职责就是定义这些ECU之间的连接方式与网络拓扑结构。
电子电气架构.jpeg
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内核分类
内核（kernel） 是操作系统最核心的部分，可以理解为操作系统的心脏，分为三种类型：
微内核的好处是小、稳定，可以实现 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.png
智能座舱
以产品设计为驱动力，但目前同质化现象比较严重，主要以硬件差异为基础，只能利用先发优势，无法形成技术与产品壁垒！
基于用户画像，使用AI技术，构建具有情景感知能力的引擎，是智能座舱产生质变的前提，但技术上短期无法突破(行业普遍问题，不是车行业特有）。
多设备协同、多模态融合交互，是消费电子IOT场景下大家探索的方向，对于车载环境有很强的借鉴意义。
自动驾驶
以算法与数据的积累为核心驱动力，可以在技术上形成壁垒，但是需要巨额的研发投入，能否快速落地主要受制于数字系统架构。短期来讲大家可能都差不多，但是积累到一定时间，后发玩家可能就再也追不上了。
数字系统
以架构设计与资源整合为核心驱动力，其包含了传统意义上的电子电气架构，但需要横向整合多个软硬件架构部门，才能定义完整的系统架构。是否采用新架构从根本上决定了，智能座舱与自动驾驶究竟能走多快走多远。
良好的数字系统架构，能够屏蔽底层车型平台的差异，多个车型共用一套基础软硬件平台，能够缩减开发资源，一套架构持续５年，可以留出充足的资源研发下一代。
第二篇
上一篇文章主要介绍了电子电气架构、车载操作系统、基础软件平台等之间的关系，以及软件定义汽车的基本概念，本篇将继续深入，重点阐述三个问题：
- 智能电动汽车软件范畴
- 软件+硬件升级的基础
- 面向服务的软件架构设计
一、智能电动汽车软件范畴
按照新能源汽车的特点以及中央计算电子电气架构的发展趋势，可以按照以下三个类别，对智能汽车软件进行分类：动力与底盘控制器、车身控制器、中央计算单元。
智能电动汽车软件分类.jpg
动力与底盘控制器
底盘类的功能，包括电子转向（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就是要求各个控制器，把自己的能力，以服务的方式提供出来，以此来构建一个与车型、芯片、操作系统无关的灵活可变的平台系统。
- 服务内高内聚，功能完整，可复用
- 服务间低耦合，无依赖
- 服务通信接口标准化，不依赖于平台实现。
下面举个例子来说明，在中央计算电子电气架构下，以以太网为通信方式，把各个控制器提供的功能按服务的维度进行拆解（以下只是示意，主要为了讲清楚原理，服务的分类、拆解、分层，是一个架构设计的细活儿，是一个系统性的工作）。
面向服务的架构设计举例.png
上面这张图，软件上的分层看起好像和传统软件的架构也没太大区别，其实这里面最关键还是服务间的连接关系，其核心是需要SOA框架软件的实现一套服务管理的框架，类似与IT领域所说的 UDDI（Universal DescriptionDiscovery and Integration，统一描述、发现和集成），提供服务发布、查找和定位的方法。在这个框架下，服务节点可以动态加入，并且按照统一标准实现的所有服务都是对等的，服务之间可以动态的建立订阅/发布的关系，且相互之间以一种中立的服务描述语言为契约，是一种松耦合的关系。
服务可以分为三类，原子服务、组合服务、流程服务，原子服务提供的是最基本的功能，比如获取传感器的数据、升降车窗指令；组合服务是利用多个原子服务，实现了部分判断逻辑，比如升降车窗并不是任何条件下都能执行，还需其他条件去综合判断；流程服务，是根据业务功能定义的服务，比如产品上定义一个抽烟模式，需要同时打开车窗、天窗，并播放车主收藏的音乐，这就需要调用多个组合服务去实现。
原子服务，一般和硬件功能有关，硬件功能决定了原子服务的范围；组合服务，可以认为和某种策略和控制逻辑相关，比如实现一种新的驾驶模式；流程服务，可以认为是和特定场景下的产品功能。在SOA的软件框架下，“软件定义汽车”就变成了，在一个完备的原子服务集合当中，通过定义新的组合服务与流程服务，去实现新的产品功能。而在硬件可升级的前提下，又可以通过硬件升级，去拓展原子服务的功能范围。比如，换了带V2X的中央计算单元，就可以新增V2X相关的原子服务，然后定义一个新的流程服务，如，基于V2X的紧急刹车。
当然新的架构，也一定会带来新的挑战:
- 架构设计的挑战， 比如上面提到的服务的拆解、分类、分层，这类工作往往具有一定的灵活性，需要不断地去摸索和总结最佳实现。
- 功能安全的挑战，传统AutoSAR，功能静态部署，可以对每个分支流程，做危害分析，而SOA功能可以动态部署，无法预先做到每个场景都覆盖到。
- 信息安全的挑战，传统的离散系统，造成信息孤岛的同时，也无形之中构建了一道物理防火墙，现在服务都变成了对等节点，就需要一套完整的权限控制解决方案。
结语
本篇主要对智能汽车软件的范围、软硬件升级、SOA的内涵进行了介绍，下一篇将重点介绍，SOA实现的基础；对常见的技术概念，车载以太网、SOME/IP、DDS、Adaptive AutoSAR、ROS2 等，梳理各自所处的技术层次与要解决的问题，阐述其与SOA的关系。
第三篇
上一篇文章对智能汽车软件的范围、软硬件升级、SOA的内涵进行了介绍，本篇将围绕 SOA的实现细节，重点阐述以下问题：
- SOA 基础软件框架
- SOA 参考实现
- SOA 实现所需相关技术
一、SOA 基础软件框架
上一篇中，介绍了面向服务的软件架构设计SOA，但它只是一架构种设计思想，本身并不是一个软件模块。工程中需要一个基础软件框架去实现其架构设计思想，下图中的 SOA Framework 就是我所说的基础软件框架。
SOA Framework.png
上图中所表示的就是一个典型的中央计算电子电气架构，几十个 ECU 的功能，集中到少数计算单元上，大部分 ECU 消失了，但是由于底盘域的特殊性，依然保留了部分 ECU 的功能。几大控制器，选用的都是高性能的 SOC（画3个只是示意），由于工作任务的不同，选用了不同的操作系统。SOA Framework 是这个分布式软硬件系统运行的关键，具有以下特点：
- 它是一个操作系统中间件
- 运行在不同的OS 内核之上，可以跨平台。
- 除了基于以太网，最好还能兼容传统 AutoSAR
- 需要为上层应用提供良好的开发接口。
- 需要与多个 SOC 上的 SOA Framework 进行分布式协同。
SOA Framework 架构.png
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.jpg
ROS2 最大的改变是，取消Master中央节点，实现节点的分布式发现，发布/订阅，请求/响应通；底层基于DDS通信机制，支持多操作系统，包括Linux、windows、Mac、RTOS。要把 ROS2改造的完全适合车载，还有不少工作要做，之前提到的 APEX.AI公司，就是在做这个事情。
Classic AutoSAR 是开发 ECU 的主要标准 ，相关的介绍网上很多，就不多做介绍，Adaptive AutoSAR 2017年才发布第一个release 草案，主要用于高性能 SOC，运行在兼容 POSIX的操作系统之上，其也运用了 SOA 的架构设计思想。
adaptive autosar.png
从Adaptive AutoSAR 和 ROS 当中，能够看到德系与美系架构设计思想之间鲜明的差别。我的第一感受是，美系架构设计更加简洁、灵活，追求开源。而德国人喜欢把简单的问题复杂化，喜欢过度设计，搞很深的抽象层次，喜欢搞代码生成，喜欢强绑定 IDE，这可能与他们工程师思维的严谨性有关系，总之搞得看起来门槛特别高，相关的公司还可以卖标准，卖工具，赚的盆满钵满。
传统 ECU 开发中，Classic AutoSAR 依然会占主导地位， 德系公司是毫无疑问的主导者，但是我个人并不看好 Adaptive AutoSAR 的发展，主要有以下几点:
- 其标准的推进事实上已经落后于行业应用。
- 在自动驾驶的发展方面，中美是主导，德国已经无法实现他在传统汽车领域的霸主地位。
- 开源软件，成就了人工智能、自动驾驶相关行业的繁荣，德系软件商这种设置高门槛，通过标准挣钱的做法，很难继续下去，一套基础软件收费超过千万，没实力的会选择开源，有实力的也会自己去开发，大家顶多借鉴一下其设计思想。
三、DDS 与 SOME/IP
DDS(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的关系，下一篇主要聊聊一些非技术性的问题，比如行业现状，落地中实际会碰到的困难等。
作者：leo_huang
来源：智车科技
微信公众号：
推荐阅读：
更多汽车电子干货请关注汽车电子与软件专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
