目录
汽车服务架构(SOA)开发设计
1.什么是SOA
1.1 SOA优缺点
1.2 SOA 应用优势
1.3 服务的基本结构
1.4 SOA架构的核心要素
1.5 SOA服务架构开发趋势
1.6 SOA与E/E架构
1.6.1 域控制为核心的架构
1.6.2 区域控制为核心的SOA架构
1.7 以服务为核心的SOA开发思路
1.7.1 AP（Adaptive Platform）的开发
a. 定义服务内容
b. 定义服务接口
c. 配置服务关系
d. 通讯协议设计
2. SOA设计
2.1 SOA 设计原则
2.2 服务构件与传统构件
2.3 关键技术
2.3.1 UDDI
2.3.2 WSDL
2.3.3 SOAP
2.3.4 REST
2.3.5 ESB
2.4 SOA实现
2.4.1 Web Service
2.4.2 服务注册表
2.4.3 企业服务总线
2.5 SOA实现基础
2.6 开发流程
2.7 开发工具链
2.8 SOA的应用实例
3. 汽车SOA开发
3.1面向服务架构的汽车软件及开发方法
3.1.1 如何分析和设计服务架构
3.1.2 如何建模和记录面向服务的架构
3.1.3 如何部署和实现面向服务的软件
3.1.4 SOA汽车软件创新平台
3.2 面向服务架构的汽车软件分析和设计
3.2.1 系统需求分析
3.2.2 系统功能分析
3.2.3 候选服务分析
3.2.4 系统架构设计
3.2.5 软件架构设计
3.3 面向服务架构（SOA）的汽车软件实现和部署
3.3.1 满足 SOA 架构的服务组件架构SCA
(Service-Component-Architecture)
3.3.2 服务组件架构SCA的配置描述
3.3.3 汽车SOA软件的实现方案
3.3.4 SOA服务组件实现和部署的具体步骤
3.4 核心模型设计
3.5 图表设计
3.6 服务设计
3.7 AP平台SOA相关技术规范概述
4. SOA流程开发在自动驾驶车企中布局
5. 企业管理开发流程与SOA软件架构开发之间的关系
6. SOA的两种不同开发模式原理
6.1业务驱动型开发
6.2平台驱动型开发
7. 基于AUTOSAR的SOA开发
7.1 基于AUTOSAR的SOA软件架构
7.2 基于SOA构建软件设计方法
7.3 系统架构-虚拟功能总线
7.4 SOA软件分层
7.4.1 应用软件
7.4.2 实时运行环境
7.4.3 基础软件
7.5 基于AUTOSAR的SOA服务
7.6 硬件抽象
7.7 基于AUTOSAR的SOA系统配置
8.总结
1.什么是SOA
SOA (服务导向架构，Service Oriented Architecture) 作为一种架构范式，展示了技术中立的最佳实践。其建立在标准之上，可在供应商的广泛支持下在全球范围内实现经济高效的实施。以在企业内部和跨企业创建新业务功能方面重用和重新组合服务，SOA很好的做到了“粗粒度”和“松散耦合”的特点，相较于当前分布式物理架构具有更大的灵活性。SOA 最佳实践创建包含业务流程的设计 —— 并增强将流程外包和扩展给业务合作伙伴的能力。此外，SOA也可以复用已有的系统和流程，与传统的基于孤岛的应用程序开发更具战术性的本质形成对比，可以保留和增强现有投资承建的架构、软件等实现的部分有用性。
1.1 SOA优缺点
优点：
- 扩展方便：可针对单个服务提供资源扩展
- 语言通用：接口通用，服务可以基于任何语言
- 新人友好：单一模块服务理解透彻即可服务此模块，不必理会架构
- 发版方便：可更新单一模块，不影响架构
缺点：
- 问题排查不便：功能调用服务多，很难直接定位问题点
- 沟通不便：模块独立，不确定其他模块状态
- 性能问题：通信时间损耗
- 关系混乱：服务越来越多，调用方越来越多的时候，就会比较混乱
- 运维难度：随着服务的增多，系统架构会越发复杂，这就给运维层面带来了挑战
- 数据一致性问题：单体项目因为数据都在同一个数据库里面，不需要过多的关注分布式事务等问题，SOA就需要关心了
1.2 SOA 应用优势
早期的车内嵌入式软件没有统一标准，基础软件和应用软件强耦合，不具可移植性；AUTOSAR Classic 的应用，对嵌入式基础软件的接口进行标准化，让应用开发者基于统一的基础软件接口进行应用开发。目前采用SOA软件服务架构的应用打通了车内的电子电气架构的壁垒，进一步对嵌入式应用软件的接口(即服务接口)进行了标准化，让APP开发者基于统一基础服务接口进行应用的迭代开发，隐藏了不同车型配置下应用软件的差异，真正做到了整车级软件接口的”标准”和”开放”。
平台架构升级更便于实现，通过服务设计的方式，能够有效降低架构升级带来的复杂度；同时，由于操作系统跨平台的难度大幅度降低，能够大幅提升用户体验，能够实现更为便捷的联网功能，实现不同平台间的各种APP共享等功能；
通过“服务Hub”区域控制器的引入，各种新功能能够灵活地与其他域功能，乃至互联网接口集成，而无需各个控制器各自进行信号到服务的转换；
一些相对独立的域开发能够打破界限，找到新的上限，例如自动驾驶功能不再是电子电气架构“孤岛”，通过区域控制器进行服务互通，可以轻松实现高清地图的创建、更新及路线预测等功能，便于实现车辆信息的上传及云端指令的下达。
1.3 服务的基本结构
独立的服务结构如下图
服务模型的表示层从逻辑层分离出来，增加了服务对外的接口层。通过对服务接口的标准化描述，使得服务可以提供给在任何异构平台和任何用户接口使用。这允许并支持基于服务的系统成为松散耦合、面向构件和跨技术实现，服务请求者很可能根本不知道服务在哪里运行、是由哪种语言编写的，以及消息的传输路径，而是只需要提出服务请求，然后就会得到答案。
1.4 SOA架构的核心要素
要准确全面理解SOA，首先必须理解SOA的核心要素：
SOA的目标就是实现灵活可变的IT系统。要达到灵活性，通过三个途径来解决：标准化封装、复用、松耦合可编排。
互操作(标准化封装)、复用、松耦合等SOA技术的内在机制，也是中间件技术和产品的本质特征。
标准化封装（互操作性）
传统软件架构，因为封装的技术和平台依赖性，一直没有彻底解决互操作问题。互联网前所未有的开放性意味着各节点可能 采用不同的组件、平台技术，对技术细节进 行了私有化的约束，构件模型和架构没有统一标准，从而导致架构平台自身在组件描述、发布、发现、调用、互操作协议及数据传输等方面呈现出巨大的异构性。各种不良技术约束的结果是软件系统跨互 联网进行交互变得困难重重，最终导致了跨企业/部门的业务集成和重组难以灵活快速的进行。
在软件的互操作方面，传统中间件只是实现了访问互操作，即通过标准化的API实现了同类系统之间的调用互操作，而连接互 操作还是依赖于特定的访问协议，如JAVA使用RMI，CORBA使用IIOP等。而SOA通过标准的、支持Internet、与操作系统无 关的SOAP协议实现了连接互操作。而且，服务的封装是采用XML协议，具有自解析和自定义的特性，这样，基于SOA的中间 件还可以实现语义互操作。
SOA要实现互操作，就是通过一系列的标准族，来实现访问、连接和语义等各种层面的互操作。
软件复用
软件复用，即软件的重用，也叫再用，是指同一事物不作修改或稍加改动就多次重复使用。从软件复用技术的发展来看，就 是不断提升抽象级别，扩大复用范围。最早 的复用技术是子程序，人们发明子程序，就可以在不同系统之间进行复用了。但 是，子程序是最原始的复用，因为这种复用范围是一个可执行程序内复用，静态开发 期复用，如果子程序修改，意味着所有 调用这个子程序的系统必须重新编译、测试和发布。
SOA的复用
为了解决这个问题，人们发明了组件（或者叫控件），如MS操作系统下的DLL组件。组件将复用提升了一个层次，因为组件可以在一个系统内复用（同一种操作系统），而且是动态、运行期复用。这样组件可以单独发展，组件与组件调用者之间的耦合度降低。
为解决分布式网络计算之间的组件复用，人们发明了企业对象组件，如（Com+,.NET,EJB等)，或者叫分布式组件。通过远程对象代理，来实现企业网络内复用，不同系统之间复用。
传统架构的核心是组件对象的管理。但分布式组件也是严重依赖其计算环境，由于构件实现和运行支撑技术之间存在着较大的 异构性，不同技术设计和实现的构件之间无法直接组装式复用。
而现代SOA的重要特征就是以服务为核心，如WebService,SCA/SDO等。通过服务，或者服务组件来实现更高层次的复用、 解耦和互操作，即SOA架构中间件。
因为服务是通过标准封装，服务组件之间的组装、编排和重组，来实现服务的复用。而且这种复用，可以在不同企业之间，全球复用，达到复用的最高级别，并且是动态可配置的复用。
耦合关系
SOA架构在松耦合解耦过程也发展到了最后的境界。传统软件将软件之中核心三部分网络连接、数据转换、业务逻辑全部耦 合在一个整体之中，形成“铁板一块”的软件， “牵一发而动全身”，软件就难以适应变化。分布式对象技术将连接逻辑进行分 离，消息中间件将连接逻辑进行异步处理，增加了更大的灵活性。消息代理和一些分 布式对象中间件将数据转换也进行了分 离。而SOA架构，通过服务的封装，实现了业务逻辑与网络连接、数据转换等进行完全的解耦。
SOA不断解耦的过程
总之，从科学哲学的角度来看，SOA是一个不断解构的过程，传统软件强调系统性，耦合度过高，所以需要松耦合（解耦）；SOA也是一个组件粒度的平衡，集成电路趋势是集成度越来越高，软件发展的趋势是相反的过程；SOA是架构，更是 方法，反映了人们对哲学思想的追求的原动力。
按照这个特性，SOA基本上来说与WebService并不是同一个概念，SOA并不一定需要WebService实现，理论上可以在其他技 术体系下，实现SOA。但事实上，到目前为止，能够实现SOA架构风格的技术就是WebService，因为它的特性和厂商的支持 力度，使得WebService成为了实现SOA实现技术的事实标准。也正因为WebService技术的成熟，才使得已经提出10多年了的 SOA思想和概念，得以能够实现落地，成为一种可以使用的技术。这也就是回答了SOA和WebService的关系。
1.5 SOA服务架构开发趋势
传统汽车使用由上百个ECU组成的分布式EE架构，OEM定义对各ECU的功能需求，由不同供应商负责最终功能实现。这种架构导致大量功能控制逻辑在子节点ECU内部完成，传感器、执行器信号被掩埋在分布网络下，仅通过在局部网络的ECU部署基于服务的通讯，无法实现对整车硬件能力的充分暴露。且考虑到基于SOA软件平台，未来SOP后的车型也需具备硬件冗余能力以应对OTA软件升级，上百个ECU的冗余设计将极大增加成本支出，也导致跨域功能OTA的实现将涉及数量众多的ECU。
随着车载芯片算力的提升和高带宽、低时延车载以太网通讯技术的落地，EE架构已从分布式演进至域集中 (Domain Centralized)，并向整车集中＋区域 (Vehicle Computer & Zonal)、整车集中 (Vehicle Centralized)不断进化。在高集成度的EE架构下，域控制器将承担整车主要逻辑，而执行器、传感器将成为纯粹的执行机构，执行控制命令或是提供环境感知数据。
基于整车集中EE架构的“硬地基”， SOA在域控制器上的部署才能够实现整车能力的资源获取，并将其封装为标准的服务和接口向应用层开放。
1.6 SOA与E/E架构
1.6.1 域控制为核心的架构
电子电气架构的概念从总线引入汽车开始就不断更新和演化，如今一套完整的整车数字架构所考虑的内容除了传统的拓扑、网络、线束与电气分配、逻辑功能分配，还需结合整车的功能/信息安全架构、数据架构、计算架构，以及实现通讯架构与软件架构的协同，功能架构与服务架构的协同，车内服务与云端服务的协同。
如图所示：域集中架构在连接上由功能域控制器，分别通过子网与各功能域内ECU相连接，而域控制器之间则修建通讯“高速公路”，通过高带宽的骨干网络相连。拓扑结构只是架构的表象，而表象背后的核心特征是功能逻辑被抽象上移至功能域控制器中。每个域控制器有对应的集成的（Signal to Services）, 在域控制器中进行功能的分配、功能的集成。而某个域控制器作为云端链接的桥梁，将平行的几个域控制器的逻辑运算功能输入到云端。功能逻辑运算服务的重心在域控制器中。
1.6.2 区域控制为核心的SOA架构
如图所示：整车集中和区域架构在连接上是通过分布在车内各物理区域的区域网关/控制器将车内物理I/O分别就近连接和控制，形成整车数字系统的“手”和“脚”，然后通过骨干网络与系统中的“大脑”控制单元进行连接。连接关系同样只是表象，而核心价值在于将车内软件（运算）和硬件解耦，彻底实现软件独立“生长”（或者说算力架构可以迭代，共享算力变成了可能），而硬件同样可以独立“生长”（跨车型平台，或者在车辆生命周期内为用户提供升级服务，而这些在传统架构中实现的成本是不可控的）。
1.7 以服务为核心的SOA开发思路
虽然电子电气架构开发从理论上是正向开发，但实际上一款车型的开发并不是完全从零开始的，很多功能方案会沿用老款车型。这样的后果是，系统和软件模块已经固定，即无法通过正向设计的思路拆解逻辑，设计服务。考虑这种情况，服务设计可以分为以下两种方法。
(1)自下而上的方法
适用于现有平台上已实现的功能或系统。此种方法的基础是，功能的网络分配，通信，ECU软件架构，功能规范和使用场景等都已经有明确定义。我们可以利用现有的这些输入，完成将原有功能对SOA的转换。
适用功能和系统：
- 车身舒适的大部分功能，如车门，车窗，座椅，空调等，功能逻辑没有太大争议，就可以通过现有子系统规范和网络信号清单，进行服务接口设计。
- 动力和底盘系统。这是整车中对安全要求最高的两个系统，因此一般来说，我们在设计第一代SOA架构时。这两个系统更适合自下而上的方法，通过对已有功能的提取，转换为服务接口，接入整车服务系统。
- 传感器和执行器资源。汽车上的每个元件都代表了一种基础能力。基于整车传感器和执行器清单，能够快速形成一份基础服务清单。由此出发，再通过功能梳理，层层往上，可以形成更加丰富多层次的服务列表。
(2)自上而下的方法
自上而下的方法即为正向设计方法。在基于SOA的电子电气架构开发中，对于复杂功能，或者引入到平台中的新功能和新系统，必须遵循这种方法完成服务设计。基于上述所介绍的开发流程，从需求出发，进行逻辑拆解，服务拆解，软件架构搭建，系统设计等。这个方法所依赖的输入一般是功能需求表和用户场景。
不管使用哪种方法，通常服务的设计是在单个功能或系统级别定义的，最后需要架构师综合考虑整车系统，将高度复用性的服务归类为平台级通用服务。通用服务池子是“生态共创”的基础。
服务的分类：
- 硬件抽象服务根据ECU的功能和硬件外围设备（传感器和执行器），定义硬件抽象服务。这些服务同时属于平台级核心服务。示例：Camera interface，Rain sensor interface
- 平台级核心服务在应用程序集群和域之间通用的所有服务。示例：Power mode，Vehicle speed，Key status
- 域级核心服务在域内的应用程序集群内不同应用程序之间通用的服务。示例：Front vehicle distance calculate，Front obstacles
- 应用服务为每个特定的应用程序或系统功能服务的服务。示例：Enable ACC，AEB system status
服务设计的输入要求：
(1)应用级别的服务
- 功能和系统描述，用户场景描述
- 功能和系统需求
- 功能和系统逻辑架构
(2)平台级别的服务
-
来源：不懂汽车的胖子
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！