汽车服务架构(SOA)开发设计

目录

汽车服务架构(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优缺点

优点：

1. 扩展方便：可针对单个服务提供资源扩展
2. 语言通用：接口通用，服务可以基于任何语言
3. 新人友好：单一模块服务理解透彻即可服务此模块，不必理会架构
4. 发版方便：可更新单一模块，不影响架构

缺点：

1. 问题排查不便：功能调用服务多，很难直接定位问题点
2. 沟通不便：模块独立，不确定其他模块状态
3. 性能问题：通信时间损耗
4. 关系混乱：服务越来越多，调用方越来越多的时候，就会比较混乱
5. 运维难度：随着服务的增多，系统架构会越发复杂，这就给运维层面带来了挑战
6. 数据一致性问题：单体项目因为数据都在同一个数据库里面，不需要过多的关注分布式事务等问题，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的转换。

适用功能和系统：

1. 车身舒适的大部分功能，如车门，车窗，座椅，空调等，功能逻辑没有太大争议，就可以通过现有子系统规范和网络信号清单，进行服务接口设计。
2. 动力和底盘系统。这是整车中对安全要求最高的两个系统，因此一般来说，我们在设计第一代SOA架构时。这两个系统更适合自下而上的方法，通过对已有功能的提取，转换为服务接口，接入整车服务系统。
3. 传感器和执行器资源。汽车上的每个元件都代表了一种基础能力。基于整车传感器和执行器清单，能够快速形成一份基础服务清单。由此出发，再通过功能梳理，层层往上，可以形成更加丰富多层次的服务列表。

(2)自上而下的方法

自上而下的方法即为正向设计方法。在基于SOA的电子电气架构开发中，对于复杂功能，或者引入到平台中的新功能和新系统，必须遵循这种方法完成服务设计。基于上述所介绍的开发流程，从需求出发，进行逻辑拆解，服务拆解，软件架构搭建，系统设计等。这个方法所依赖的输入一般是功能需求表和用户场景。

不管使用哪种方法，通常服务的设计是在单个功能或系统级别定义的，最后需要架构师综合考虑整车系统，将高度复用性的服务归类为平台级通用服务。通用服务池子是“生态共创”的基础。

服务的分类：

1. 硬件抽象服务根据ECU的功能和硬件外围设备（传感器和执行器），定义硬件抽象服务。这些服务同时属于平台级核心服务。示例：Camera interface，Rain sensor interface
2. 平台级核心服务在应用程序集群和域之间通用的所有服务。示例：Power mode，Vehicle speed，Key status
3. 域级核心服务在域内的应用程序集群内不同应用程序之间通用的服务。示例：Front vehicle distance calculate，Front obstacles
4. 应用服务为每个特定的应用程序或系统功能服务的服务。示例：Enable ACC，AEB system status

服务设计的输入要求：

(1)应用级别的服务

1. 功能和系统描述，用户场景描述
2. 功能和系统需求
3. 功能和系统逻辑架构

(2)平台级别的服务

1. 跨域的系统设计文档
2. 跨域的功能清单
3. 网络拓扑
4. 传感器和执行器列表（用于提取硬件抽象服务）

因此，服务设计的输出主要为：
(1)服务的定义

1. 服务接口的定义
2. 服务提供方和消费方信息
3. 软件模块信息

对应的输出文档可以分为：

1. 服务定义矩阵
2. 服务详细设计文档（包含软件实现信息）
3. 服务数据库ARXML（涵盖通讯、服务、软件部署等信息）

1.7.1 AP（Adaptive Platform）的开发

a. 定义服务内容

此步骤实际上就是搭建了一个系统功能架构，从整车层面即是按照功能需求定义并划分服务。对于SOA中的服务表示了一种独立的功能单元，一个服务可以包含其他子服务单元，使用标准接口进行通讯，将内部信息封装成一个黑盒子，实现子服务的重用性。上层服务可以通过该标准接口调用下层服务封装的子服务内容。同时，整体的服务内容可以被操控单元远程访问和独立更改或更新。同时，对于SOA来说，需要通过服务编排来定义清楚服务之间的相互关系。
简单地说服务对于智能驾驶汽车而言就是定义产品，对其中产品的能力进行描述，这里的产品能力我们称之为PC（Product Capability）。实现这种产品能力需要从下至上定义硬件抽象服务、平台核心服务、域核心服务、应用程序服务。而每一个服务内容对应着一个或多个实现的软件模块，这里我们称之为SWC（Software Capability）

产品能力 (PC) 描述了系统所需的一些高级功能。区别于系统设计，PC是用来分配职责的，所以很清楚哪个SWC Module软件模块（如摄像头识别模块、雷达识别模块、中央域控制器模块）应该实现什么。它们在功能设计时由功能负责人识别和请求。一些系统相关的PC也可以由系统架构师或模块负责人直接识别，在模块架构工作中映射PC时，模块所有者还可以确定对更多 PC 的需求。
在确定并决定添加 PC 后，对应的软件模块拥有该 PC，模块所有者负责将其实施到正确的版本，并在平台的整个生命周期内维护/发展 PC。

b. 定义服务接口

    服务接口是一种通信内容定义，其目的在于将服务从功能架构过渡到软件技术架构，且软件模块之间的关系需要被清晰的定义出来，过程中将服务内容封装成相应的接口被实际调用。这种接口定义是独立于通信协议的抽象实体，这种接口可以建立任何两个服务间的通信能力，而使用合适的工具链可以由此生成基于特定协议的接口。
服务接口可分为方法（Method）、属性（Property）、事件（Event）三种类型。以智能驾驶的一个子功能执行接口服务为例，假设需要获取摄像头传感器探测的环境数据，而需要进行定义的服务接口中方法是要对传感器的参数进行后融合，那么就需要其底层服务提供摄像头处理的基础函数（如ISP、深度学习函数、BEV函数等）。而服务接口的属性则是通过一定的方法操作（如get/set）来获取该服务函数，这种服务属性可以对上层调用的服务部分可见，底层服务有变动上层的调用方式也会随之变动，这种变动所带来的更新会由服务底层决定何时发送给上层调用它的服务单元。
服务接口定义完整后，开发人员可以根据该接口定义对其中的函数进行定义开发了。

c. 配置服务关系

    此过程会建立软硬件之间的映射关系，实现从抽象的服务定义到软件层面的推导，从而方便实现软件驱动或调用硬件实现单元，这种结果是实现服务与中间件或底层硬件ECU之间的映射关系。从整个SOA的架构模型中我们知道服务需要从通用服务平台开始进行底层驱动，然后对上层传感器执行器的控制管理进行驱动。由于AP直接支持服务接口，可以直接面向上层应用层，CP仍然是对常用的底层应用服务的驱动映射，因此，两层驱动分别对应着经典的CP Autosar中间件调用和AP Autosar模式。

d. 通讯协议设计

    智能网联汽车的SOA架构设计需要强大的环境感知、信息处理、实施决策、控制能力可以把智能交通、地图、定位、通讯、云、大数据等进行系统集成，故车端与云端、车辆与车辆之间、车辆内部的各个ECU之间通信的速率和数据量都比传统汽车高出几个数量级，这些需要由多种复杂的硬件、软件和高速通信总线共同实现，并在很大程度上决定智能汽车的功能实现和扩展的可靠性。车载以太网能够很好的解决大数据量的信息交互，整个通信协议的定义包括虚拟以太网VLAN，以太网交换机Switch，套接字Socket，基于IP的可扩展面向服务的中间件SOME/IP，SD等。而基于AVB的下一代协议TSN（时间敏感网络）可以提供非常优秀的实时性。

    以太网通讯设计过程包含对服务实例进行通讯协议相关的信息配置。由于SOA架构中包含多个应用实体之间的多通路通信过程，且这些通信通常是网状通信，因此需要在各个实体节点之间建立中间路由、转化等。区别于传统总线（Can/Lin），在软件架构设计过程中，开发人员需要设计具体的服务类型、服务ID、服务数据类型、服务角色等。

详细内容见下面链接：

汽车服务架构（SOA）开发设计https://download.csdn.net/download/ChrisKKC/82048291

【积分下载】软件定义汽车服务API-第一部分：原子服务API参考https://download.csdn.net/download/ChrisKKC/85089142【积分下载】软件定义汽车服务API-第一部分：原子服务API参考 变更说明https://download.csdn.net/download/ChrisKKC/85089150【积分下载】软件定义汽车服务API-第二部分：设备抽象API参考https://download.csdn.net/download/ChrisKKC/85089177【积分下载】软件定义汽车服务API-第二部分：设备抽象API参考变更说明1、软件定义汽车服务2、SOA架构3、API接口参考4、设备抽象API5、变更说明更多下载资源、学习资料请访问CSDN下载频道.https://download.csdn.net/download/ChrisKKC/85089158