【爱游戏官方网站入口】软件界说汽车（1-3合集）

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

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

多领域的涉猎也给这个系列的主题，提供了差别的视角。第一篇一、互联网与传统汽车人的碰撞在这个领域探索了几年，一个感悟就是，百年汽车工业，任何人也不要妄谈颠覆，可是也绝对不能拒绝进化。汽车界一直都有所谓的“传统派”与“互联网派”之间的话题争论。

传统派与互联网派都有自己的优点，但却是有明确的领域限制的，好比互联网所提倡的以用户为中心，连续打磨产物和服务的设计理念，对于传统汽车行业简直有很是大的资助。可是对于历程中所习用的敏捷开发，快速迭代，却并不能完全套用，至少是有一定前提的。

敏捷开发的前提有两个，尺度化的基础设施的支持，而且需要有良好的架构设计。互联网领域，部署代码的主要有，电脑端、移动端、服务端。每个端操作系统、应用开发框架、开发工具都很是尺度，但如果是一辆传统架构的汽车，有几十上百个 ECU，而且还来自于差别的供应商，系统集成的庞大度不是线性而是指数级此外增加，不得不有一套严苛的流程去规范整个开发流程。二、从电子电气架构的演进看软件开发分工的变化电子电气架构EEA（Electrical/Electronic Architecture），最先是由德尔福公司提出的。

汽车作为一个庞大的电子系统，根据传统界说，可以划分为车身、底盘、动力、信息娱乐、辅助驾驶等几大子系统；每个子系统又由多个电控单元 (ECU)组成，这些ECU毗连起来就形成了一个网络结构；EEA 的主要职责就是界说这些ECU之间的毗连方式与网络拓扑结构。电子电气架构.jpeg2.1 传统的漫衍式的电子电气架构的问题网络结构庞大，形成信息孤岛，中央网关会是性能瓶颈ECU冗余，算力浪费，且无法形成协同ECU 由差别的供应商开发，框架无法复用，无法统一 OTA外部开发者无法对 ECU 举行编程，无法由软件界说新的功效无法举行硬件升级2.2 差别架构主机厂饰演的角色基于传统漫衍式架构，主机厂只是架构的界说者，焦点功效是由各个 ECU 完成，其软件开发事情主要是由 Tier1完成，主机厂只做集成的事情，这也是为什么大部门传统主机厂基本没有软件开发能力的基础原因，就靠 DRE搞定供应商就能集成一辆车，为什么还要花大量的成本养一个庞大的软件团队。

基于域控制器架构，属于过渡形态，DCU 减轻了中央网关的压力，也可以实现部门业务逻辑，但大部门业务还是由各 ECU 实现，主机厂可能会到场部门 DCU 的开发，但与 Tier1的整体分工无太大变化。基于中央盘算的架构，此时大部门 ECU 消失，种种传感器与执行器，被中央盘算单元所支配，原本属于 Tier1的大部门计谋层面的软件需要由主机厂去主导，需要一只专业的软件团队，或者界说某种规范，让 Tier1实现，最后以软件模块的方式集成进来，这需要一只高水平的软件架构团队。

2.3基于中央盘算电子电气架构的优点算力集中到为少数几其中央单元，可以留有冗余便于后续软件功效升级经由良好的平台化设计之后，硬件单元也可以升级，如特斯拉的 AP该架构是软件界说汽车的硬件基础，并不是有了新的电子电气架构就能够实现软件界说汽车，这还只是万里长征第一步，还需要有一个经由良好架构设计的基础软件平台。三、车载情况下的操作系统提到基础软件平台，许多人的第一反映就是要做一个操作系统，操作系统简直是很是关键的一个组件，可是打造一个基础软件平台绝对不是再造一个操作系统3.1操作系统的界说操作系统是一种治理盘算机硬件与软件资源的盘算机法式，公共所知道的其实都是很泛化的操作系统观点，常见的观点分为四个条理。类型代表特点内核Windows NT、Unix、Linux、QNX、IOS（起源自 Unix）有自己独立研发的内核，刊行版Android、AliOS、Ubuntu、种种国产桌面系统、AGL在内核之上构建了应用开发框架，保证理，焦点服务等组件ROMMIUI、EMUI、种种 xxx.OS在 Android 上修悔改了系统服务和系统UI中间件ROS、DurerOS Apex.OS具有某种功效荟萃的操作系统中间件3.2内核分类内核（kernel） 是操作系统最焦点的部门，可以明白为操作系统的心脏，分为三种类型：类型代表特点微内核QNX、LiteOS、VxWorks只实现基本的任务治理、内存治理、历程通信等，其他包罗驱动等都在用户态实现宏内核Linux、Unix除了基本组件之外，另有网络、设备治理、文件系统等放在内核态实现混淆内核Mac OS联合了微内核与宏内核的利益微内核的利益是小、稳定，可以实现 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_链接：https://www.jianshu.com/u/1fbf94b14980泉源：简书著作权归作者所有。

商业转载请联系作者获得授权，非商业转载请注明出处。

本文来源：爱游戏官方网站入口-www.jlhyyw.com