SOA设计难点及开发梳理.docVIP

SOA设计难点及开发梳理 SOA架构理解 那么，先来理一理关于SOA： 1、软件定义汽车，E/E架构是关键 汽车电子电气架构(简称E/E架构)是指整车电子电气系统的总布置方案。在智能网联汽车产业大变革背景下，软件定义汽车理念已成为共识。传统汽车采用的分布式E/E架构因计算能力不足、通讯带宽不足、不便于软件升级等瓶颈，已经不能满足现阶段汽车发展的需求，E/E架构的变革已成为智能网联汽车发展的关键，其升级主要体现在硬件架构、软件架构、通信架构三个方面： 硬件架构升级：由分布式ECU向域控制/中央集中架构方向发展，汽车E/E架构的升级路径表现为分布式(模块化→集成化)、域集中(域控制集中→跨域融合)、中央集中式(车载电脑→车-云计算)。好处在于：提升算力利用率，减少算力设计总需求；数据统一交互，实现整车功能协同；缩短线束，降低故障率，减轻质量。 图片来自网络 软件架构升级：通过 AutoSAR 等软件架构提供标准的接口定义，模块化设计，促使软硬件解耦分层，实现软硬件设计分离；Classic AutoSAR架构逐步向Classic AutoSAR+Adaptive AutoSAR混合式架构发展。好处在于：可实现软件/固件 OTA 升级、软件架构的软实时、操作系统可移植；采集数据信息多功能应用，有效减少硬件需求量，真正实现软件定义汽车。 通信架构升级：车载网络骨干由 LIN/CAN 总线向以太网方向发展。好处在于：满足高速传输、高通量、低延迟等性能需求，同时也可减少安装、测试成本。 2、中央计算单元：E/E架构的核心 中央计算单元是E/E架构中最关键的部分，不管是按区域的架构，还是以后的纯中央计算平台，其硬件构型从根本上决定了软件架构的设计方向。中央计算单元可以分为以下三种形态： 图片来自网络 SOC分离式：将多个不同的芯片集成到一个中央计算单元上去，每个运行不同的操作系统，只是在形态上集中到了一起，各单元依然独立的完成各自任务； 硬件隔离式：在统一的计算平台上采用虚拟化方案，同时运行多个操作系统，但是各个系统依然在硬件上进行隔离，每个系统都有自己的专属硬件资源； 软件虚拟式：在统一的计算平台上采用虚拟化方案，同时运行多个操作系统，每个操作系统所使用的硬件资源，由Hypervisor层动态调配，每个系统并没有专属的硬件资源。 硬件隔离式和软件虚拟式，都采用了虚拟化方案，唯一不同点在于硬件资源是否专属，如果是专属的，就意味着资源无法动态调配，容易产生资源浪费。虚拟化方案最大的好处是，硬件上的可拓展性，如果中央计算单元采用刀片式的设计结构，可以很方便地拓展计算单元的算力，而不用替换整个计算单元。 在中央计算单元中，只需要两个操作系统即可，用于自动驾驶、车控、网关的RTOS，以及用于娱乐的普通OS(如Android、Linux)。用于娱乐的OS完全可以通过虚拟机的方式运行，用于自动驾驶、车控、网关的RTOS，可以直接运行在Hypervisor层，既能兼顾实时计算的要求，也能获得丰富的娱乐系统功能。 3、SOA：解决软件定义汽车中服务间通信的分布式架构 在软件定义汽车中，应用间跨进程或跨核的通信，必然成为软件架构设计中一个需要去解决的问题。SOA在互联网已经应用了很长时间，但在汽车行业中，算是比较新的概念。鉴于汽车的应用场景和通信需求有其特殊性，很多互联网的SOA技术，并不能照搬过来。虽然Adaptive AutoSAR采用了SOA作为通信架构(ARA::COM架构如下图)，但是Adaptive AutoSAR的应用可以说还没有普及，应该说整个行业就没什么标准的SOA中间件解决方案，几乎没有专业做中间件研发的公司，可能在国内这种慢工出细活的东西很难有什么成长的空间和土壤吧。所以，对于汽车SOA，还有很多值得我们去做的研究和尝试~ 摘自《Introduction of ARA::COM as common communication middleware》April, 2018?by?GENIVI SOA，Service-Oriented Architecture(面向服务的架构)，是一种架构思想，实施者可以根据实际情况设计SOA的技术实现。为什么要面向服务？以前用得好好的面向信号或者面向消息的通信架构怎么就不香了？面向服务的通信架构，它的优势到底在哪里，如果不能很好地理解这点，可能很难从过去面向信号的思维转变过来，也就无法体会引入SOA的价值和意义。这有点悖论哈，不去用，无法感受其奥义，但又因为没用过，对它保有质疑，过往的再拧巴，也是千锤百炼了，从零开始，谈何容易。因此，我觉得短时间内不太可能全面铺开做整车SOA，可能会在安全等级不高的域比如智能座舱先尝试SOA。 本质上SOA就是服务的集合。在SOME/IP 协议介绍一文中，我写过对于“服务