已剪辑自: http://www.uml.org.cn/car/202104024.asp?artid=23819
**编辑推荐:**本文主要介绍了新EE架构的驱动因素、 E/E架构的进化路线、基于中央服务器EE架构的复杂性及中央ECU的软件平台 – AUTOSAR Adaptive。 本文来自于CSDN，由火龙果软件Linda编辑、推荐。
汽车智能化、电子化程度的不断提高，这是大背景，这个大家肯定没异议。毕竟客户爸爸们现在很喜欢，未来会更喜欢。
这时候来了三批工程师要搞定这个事，他们首先要解决的就是怎么把车上这么多电子设备连接起来，这个设计过程就是电子电器架构
所谓「电子电气架构」，简单地说就是把汽车里的传感器、中央处理器、电子电气分配系统、软件硬件通过技术手段整合在一起。通过这种架构，可以将动力总成、驱动信息以及娱乐信息等，转化为实际的电源分配的物理布局、信号网络、数据网络、诊断、容错、能量管理等电子电气解决方案。
通俗来说，汽车是一个软硬件结合的产物，如果把它比作是一个人，「四个轮子+一个沙发」是身体，电子电气架构就相当于神经系统，负责完成各个部位的连接，统领整个身体的运作，实现特定功能。
首先是一群抱着“机械定义汽车”思维的传统车企工程师开始动作了。增加电子控制单元(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 年左右实现新一代电子电气架构的平台化。
趣闻：量产过程，不是自动驾驶工程师不努力，而是臣妾做不到哈
如果你知道整车开发流程，一定知道“冻结”这个概念，关键接口，关键零部件在每个小迭代周期都会进行冻结，以维持各个块线的合作和同步推进。
没有OTA或者域控制器之前，智能驾驶功能必须要等到底盘性能完全冻结才能开始进行标定、调教和测试，虽然多数时候会分多个迭代过程，进行多个周期的调试，但不管哪个周期，智能驾驶功能永远是拍在最后的。一旦前面的某些开发出现了延期，在量产前最着急最痛苦的就是智能驾驶工程师，因为压缩的基本都是他们性能提升和测试的时间。
自动驾驶的研发周期理论上就不可能和整车研发周期契合！
无论生物成长还是汽车制造基本都一个道理：简单构件往往会优先产生并投入工作，以支持复杂构建的产生，骨架，心肺，往往都会优先形成机能并支持大脑器官的发育，后者的成熟周期往往是最长的。不同器官需要处理的任务维度不同，因此复杂度也不同
就像小宝宝，如果它脑袋在出了娘胎后就不成长（传统电气架构），那牛津大学也要在娘胎里读了。虽然骨架，肌肉，心肺都可以在出生前健全，但10个月时间脑子的核心功能是好不了的，他需要对接外部环境。但如果可以后天学习，那ok了，差不多时候我就可以从娘胎里出来了。
OTA或者域控制器的产生，为自动驾驶等功能释放了更多空间和时间，让其开发周期和测试周期得到必要的保障。
\1. 新EE架构的驱动因素
1）半自动驾驶辅助系统、定期空中升级等复杂的电子功能将很快成为许多车辆的标准功能；这些复杂的电子功能需要新的EE架构和更高性能的ECU支持；
2）车内软件的数量和复杂度持续快速增加，汽车行业正在经历重大变革以满足新的市场需求。
3）车辆新的功能和任务所需的计算能力越来越高，微处理器作为微控制器的补充，越来越多的被应用于ECU中。一个或多个微处理器与控制器相结合，形成高性能ECU，用于对高算力的需求；这些ECU的微处理器与智能手机或PC中使用的微处理器非常相似，也需要新的软件架构。为了将这些微处理器无缝地集成到现有的车辆网络中，运行在操作系统之上的中间件需基于标准的AUTOSAR Adaptive。
4）在快速数据网络和强大处理器的支持下，重点不再是高效的数据传输，而是加强单个ECU的解耦。从而使更换单个ECU对系统其余部分的影响应尽可能小。
\2. E/E架构的进化路线
2.1 过去 - 分布式EE架构
一个功能是由一个ECU来实现的。并且还带有一组相关的传感器和执行器，并从车辆网络接收其他数据。车辆的通信矩阵描述了ECU之间的这些必要的通信通道。 但是，这种设计限制了可重用性。传感器和执行器直接连接到单个独立的功能性ECU上。 如果其他总线参与者需要使用这些值，则需要更改通信矩阵。
图1. 分布式EE架构
2.2 现在 – 域控制EE架构
典型的域有 “车身域”，“动力传动域”和“信息娱乐域”。 该EE架构的基本思想是每个域使用一个功能强大的控制器，绝大部分必要的传感器/执行器都与该控制器连接，这大大增加了在域中扩展功能的灵活性。
图2. 域控制EE架构
2.3 未来 – 中央服务器EE架构
域控制器进一步合并在大型高性能计算机服务器或计算机集群中，传感器/执行器现在作为所谓的“智能传感器”和“智能执行器”直接连接到网络，并执行机电一体化任务。 因此，它们变得独立于ECU和车辆，从而实现了具有高重用潜力的模块化系统设计。
但是，对于低成本传感器，此过程将不会具有良好的成本效益比。要使用这些传感器，它们还可以直接连接到图3中蓝色显示的集成节点ECU上。这些节点ECU还具有另一个重要功能：它们充当传感器和执行器的总线系统（即CAN，LIN，FlexRay和以太网）之间的网关。
在这个网络中，以太网代表了中央计算机方向的主总线系统。通过对传感器和执行器ECU接口的适当抽象来创建模块化和功能可扩展的体系架构。
图3. 中央服务器EE架构
3、基于中央服务器EE架构的复杂性
1）需要异构的高性能计算平台
中央服务器或集成节点域控制单元是结构比较复杂的ECUs单元。 它们通常由几个微控制器和微处理器组成。
优点1. 因为控制器和处理器的属性相互补充，因此这种异构结构提供了一些性能优势。
微控制器自身性能优势：
a、微控制器的启动时间更快，上电启动后，它可以快速进行操作，因此可以参与与其他ECU的通信并执行其功能。
b、微控制器甚至可以满足微秒级范围内具有低抖动的最高时序要求。
c、微控制器也更适合那些需要其频繁中断的功能；
微处理器自身性能优势：
a、使用的计算内核提供了更高的时钟速率，并带来了许多功能，例如高多标量或跳跃预测，可提高平均性能。
b、较大的高速缓存还允许连接速度较慢但较大的外部存储设备。
c、除了更多的资源容量之外，微处理器还提供了更好的硬件虚拟化支持，从而使管理程序（hypervisor）技术的使用更加容易。
优点2. 具有微控制器和微处理器的异构计算单元的另一个优点在于可以满足安全要求。 按照ISO26262标准来看，当前处理器的安全完整性等级达到ASILB。通过使用冗余，仍然可以实现高度自动驾驶所需的ASIL D等级。
在这样的系统中，冗余的微控制器执行两项任务：一方面，它执行监视功能；另一方面，它也可以用于在发生故障时提供降级的功能，以便系统能够继续以高度的可靠性执行其功能。
图4. 基于AUTOSAR Classic and Adaptive两种平台的自动驾驶系统典型安全架构分析
2）高性能异构计算平台（高性能ECU）内配备了多个可编程组件
在高性能ECU内部，许多独立的软件组件共同实现ECU的功能。这在技术层面和组织层面都具有挑战性。
从技术角度来看，组件必须能够相互通信以提供通用功能。ECU制造商的任务现在是通过使用处理器间通信（IPC）连接组件并描述交换的数据。 对于ECU制造商而言，这是一项新任务，因为在先前的工作流程中未执行此步骤。然而事实是到目前为止，只需描述ECU之间的数据交换。并且这一责任完全由车辆制造商承担。这同样适用于系统的诊断功能、软件更新和网络管理。在未来，ECU简单的单独由一方定义的方式将会变成由多方进协商后来共同完成。
从组织的角度来看，集成各种软件组件是一个日益严峻的挑战。 ECU的模块化设计和POSIX兼容的操作系统使集成来自多个独立团队的软件变得更加容易。然而，因此，ECU集成商的角色变得越来越复杂。这使得用专业的工具来支持ECU集成商完成其具有挑战性的任务变得更加重要。
4、中央ECU的软件平台 – AUTOSAR Adaptive
在软件开发中对性能和灵活性的不断增长的需求以及对成本的敏感度的不断提高要求整个供应链的广泛变化。AUTOSAR Adaptive是必不可少的软件组件平台，它将为将来高性能ECU的发展做出重大贡献。
在微处理器上执行的软件组件通常不基于AUTOSAR Classic标准。 而是使用AUTOSAR Adaptive标准以满足对模块化，动态性和更新功能的要求。
AUTOSAER Adaptive 基础介绍：
1）AUTOSAR Adaptive 中间件使用兼容POSIX的操作系统，例如Linux，PikeOS或QNX；AUTOSAR Adaptive的主要功能之一是通信层ara :: com。 这样就可以与其他AUTOSAR Adaptive应用程序以及车辆中的其他软件组件（SWC）通信。
图5. ATUOSAR Adaptive 软件结构示意图
2）AUTOSAR Adaptive允许在运行时建立动态通信路径。 这种动态性是可以在运行时安装的应用程序软件的先决条件。 经典的通信矩阵必须进行修改才能将新内容发送到ECU。但是，通过面向服务的方法，可以订阅信息；
3）硬件驱动程序和高级软件更加严格地分开。 因此，车辆中与硬件无关的应用程序具有很高的便携性。与AUTOSAR Classic ECU相比，这可以实现更大的资源优化。例如，如果超过了资源限制，开发阶段的软件可以很容易地在不同的ECU之间移动，以避免硬件设计的更改。
4）另一个优点：软件组件在几种车型上的可重用性正在提高。在AUTOSAR Adaptive项目中，软件与硬件的分离还可以使车辆制造商和供应商之间进行全新的工作分配。 以前，功能总是作为车辆中的物理设备订购的，而现在可以通过软件完全购买。
已剪辑自: http://www.uml.org.cn/car/202202151.asp?artid=24892
编辑推荐:本文主要聊一聊软件定义汽车的话题中心-中间件 什么是汽车软件中间件 ,汽车软件中间件有什么好处 , 汽车软件中间件有什么缺点 ，希望对您的学习有所帮助。 本文来自于知乎 ，由火龙果软件Alice编辑、推荐。
工程师们把硬件折腾的差不多了，嗯，是不是可以开始应用软件快乐的开发了，还不是哈，我们都知道手机，电脑啥的在应用之下，硬件之上，还有一个东西叫 操作系统，车辆里也有类似的东西。
操作系统，中间件，应用软件-各司其职分工不同
操作系统-我负责对硬件，提供线程创建等服务，其他我不管
中间件-我负责和不同操作系统对接，并给上面应用提供通讯，资源管理等服务，其他我不管
应用软件-嗯，剩下都我的事，我管功能，不同系统，不同硬件的事我不管。
中间件(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的独立核心伙伴。
在2013年，AUTOSAR联盟进入一种持续改进模式，主要用来维持标准和提供所选择的改进,往后实际上，autosar更新就很少了，开始转向AUTOSAR-Adaptive。
AUTOSAR-Adaptive拯救AUTOSAR
对于用于实现典型动力总成和底盘功能的深度嵌入式系统，AUTOSAR经典平台仍将是首选。在低成本硬件上运行时，对安全性、实时性和确定性要求较高。同时，AUTOSAR为这些应用程序提供了一个经过良好验证的成熟软件平台，包括一个广泛使用的方法，它支持当今所有的协作模型。而为了支持客户应用程序的动态部署，并为需要高端计算能力的应用程序提供环境，AUTOSAR在2017年推出了第二个软件平台，即AUTOSAR Adaptive platform。这个想法是尽可能从其他领域(如消费电子产品)的发展中获益，同时仍然考虑汽车的特定要求，如功能安全。
Adaptive需要支持，未来E/E架构的两个关键特征是：
异构软件平台的集成，当今汽车的网络架构可以聚集成不同的领域，用于信息娱乐和连接、底盘、动力系统等。虽然infotainment ECUs通常使用Linux、QNX或其他通用操作系统，但AUTOSAR Classic平台是深度嵌入式控制单元的标准。随着新的用例和对计算能力的深入嵌入式应用程序不断增长的需求，第三种ecu将出现，它具有不同的特性，必须集成到现有的E/E体系结构中。
面向服务和基于信号的通信，传统的汽车通信仍然是基于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 )是应用软件和基础软件通信的桥梁，无论通信发生在 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资源、系统限制）以及模版来减少这些厨师系统设计决定的正式描述。模板包含三部分：
配置步骤如下
输入的系统配置文件借助 配置系统（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中得到的信息生成可执行程序。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8UyqPOTV-1682909930873)(null)]
AUTOSAR 的特性使得当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显著提高了汽车电子嵌入式软件的复用性——层级越高者，复用性越强。值得注意的是：
AUTOSAR在定义软件架构和接口的同时。也定义了易于交换的硬件平台标准。AUTOSAR标准不仅提供了基础软件模块的规范。还提供了用于开发分布式系统应用软件的方法。这种方法以基于模型的软件和分布式系统描述开始。以自动代码生成和可重复的测试结束。
Autosar也定义了与网络总线接口相关的模块，CAN,LIN等网络总线接口驱动、诊断等。AUTOSAR的出现使得ECU中的软件包括网络总线通信软件第三方供货成为可能。未来的网络总线标准是否仍然各自独立、互不兼容，目前还无法断定，但AUTOSAR却实实在在地将部分标准公开化、标准化，兼容化，而且实际的产品也已经被应用，AUTOSAR已对现在相互之间封闭的网络总线标准形成挑战。
此外，AUTOSAR还定义了一套标准的软件开发流程，从系统建模到生成可执行的代码，包括软件组件设计、系统配置、ECU配置和代码生成三大流程，如图
技术细节-AUTOSAR ADAPTIVE架构介绍
已剪辑自: http://www.uml.org.cn/soa/202207221.asp
**编辑推荐:**本文主要介绍了 汽车领域为什么采用SOA架构？用了SOA有什么好处？以及 对SOA架构的开发思想梳理，希望对您的学习有所帮助。 本文来自于知乎，由火龙果软件Alice编辑、推荐。
好了，硬件折腾过了，中间件也有了，是不是就可以愉快的应用开发了，不，还有一个共享的思想必须掌握，接上两篇文章
1.整车电子电气架构EEA
2.软件定义汽车-软件中间件（Autosar为例）
中间件有了，只是我们和硬件完成了剥离，但在和其他模块的交互机制上仍然存在问题，这里先要聊下单播，组播和广播三个概念。
这三个概念，原本来源于计算机以太网通讯（就如软件定义汽车，现在车辆也用了这个概念）
单播(unicast): 是指封包在计算机网络的传输中，目的地址为单一目标的一种传输方式。通俗理解就是一对一通话，这种通讯方式稳定性好，但如果有多个人需要这些信息就不划算，每个人开一个频道就会占用很大的通讯带宽。
组播(multicast): 也叫多播， 多点广播或群播。 指把信息同时传递给一组目的地址。它使用策略是最高效的，因为消息在每条网络链路上只需传递一次，而且只有在链路分叉的时候，消息才会被复制。这种模式一般有订阅和发送方两个角色，只有订阅了，才会被发送，是介于单播和广播之间的一种方式。按需定制，效率平衡。
广播(broadcast): 是指封包在计算机网络中传输时，目的地址为网络中所有设备的一种传输方式。实际上，这里所说的“所有设备”也是限定在一个范围之中，称为“广播域”。这种方式就是广场上用喇叭讲话，广场上的人都听的见。
整车现在采用了什么机制？
目前整车使用的一般是哪种？准确来讲应该是网关固定设计的单播，加独立CAN网内部的广播叠加的综合机制。
中间的是网关，旁边的都是独立的CAN网络或者其他网络，假设信息要共享，就会是这样
灰色连线内部如果要接受或者发送信息则都能够接收到（CAN的特性决定），如果要跨越几个控制器，就要经过上面一层的网关。 网关里面谁给谁发，都是预先设定好了的单播策略。我们也称这种架构为signal oriented架构，面向信号的架构。
这种机制有没有问题，现在没有什么问题，因为发布即锁定，大家按照既定的来做就可以了。但如果需求发生变化情况就不同了。面向信号的架构，大家都依赖信号设计，而这些可不好改
为啥要用SOA呢？用了SOA有什么好处？
SOA是IT行业近年来典型的架构方式，大量的IT系统都是基于SOA实现的。而汽车领域采用SOA架构的一个主要原因就是能够加快车辆与互联网的互联互通。
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是基于下一代智能网联架构来实现的，主要是完成服务实现，并且体现服务复用性而进行的设计工作，使服务本身具备高内聚，服务之间能够低耦合，提高服务的可重用性，明确边界概念。
