文章目录

  • 一文聊聊面向服务架构的汽车软件分析和设计
  • 联合电子：面向服务架构（SOA）的汽车软件三部曲
  • 汽车SOA架构
    • **SOA是什么**
    • SOA Benefits
    • SOA == Some/IP?
    • 服务接口的主要分类
    • 基于总线 VS SOA
    • SOA中的角色
    • 哪些传统架构中的服务和信号可以通过SOA来实现

一文聊聊面向服务架构的汽车软件分析和设计

已剪辑自: https://www.eet-china.com/mp/a153988.html

本文将先重温下SOA架构的核心要素与优势，并重点讨论话题“面向服务架构（SOA）的汽车软件分析和设计”。

为什么要引入汽车SOA软件?

SOA作为一种面向服务的架构，是一种设计思想和方法论。在SOA架构中，服务是最核心的抽象手段和系统最基础的描述单元。

每个服务组件具备独立的功能，且可被复用；服务组件之间的接口遵循统一标准，可互相访问，可组合扩展。业务过程则是带有状态和服务调度策略的服务组件的组合与扩展(图1)。

通过SOA架构，可整合规划OEM在不同操作系统，硬件平台上(控制器)上的业务功能，实现对功能的快速迭代和重组，应对灵活多变的智能网联趋势下的业务需求。

图１ SOA架构模型

结合未来汽车域导向型电子电气架构(Domain-Oriented)和区域导向型电子电气架构(Zone-Oriented)，应用SOA架构可实现业务过程(功能)的快速迭代与灵活重组，为智能网联趋势下的软件个性化与创新需求提供了良好的平台性解决方案。SOA架构应用于汽车新电子电气架构下的优势(图2):

车辆功能软件实现软硬分离

由于服务组件接口“标准可访问”，且描述方式独立于硬件平台和操作系统，因此组件功能可脱离硬件平台任意部署移动，对于算力有要求的复杂功能组件可向具备高带宽大算力的域控制器移动。

一些使用频度很高且基础的功能可作为基础服务组件先被开发，由于服务组件的独立性以及接口的标准可访问，基础服务开发完成后可向服务中间件注册，并供所有电子电气架构中的控制器订阅使用。

车辆功能在SOP后可新增(扩展)

“小”的基础服务可组合成为“大”服务，“大”服务可进一步组合扩展并最终构建出新的业务过程，实现OEM的业务目标。结合OTA技术，用户可在车辆使用期限里，订阅一个类似，“预测性能量管理”的新功能并安装于域控制器上，新功能的业务逻辑依赖于一些已有的服务组件(eg:预测性能量管理依赖于能量管理策略，地图预测信息等基础服务)。

图2 新汽车电子电气架构中的SOA架构应用

面向服务架构的汽车软件分析与设计

面向服务架构的开发过程从整体上可以概括为6个步骤，分别是：面向服务分析、面向服务设计、服务开发、服务测试、服务部署和服务权限管理，如图3所示。其中，分析和设计面向服务的架构是开发SOA软件的开端，也是判断系统是否基于SOA架构的最重要且核心的环节。

联合电子对分析和设计面向服务架构汽车软件的具体流程与方法进行了探索，将面向服务的分析分解为系统需求分析、系统功能分析、候选服务分析三个子步骤，将面向服务的设计分解为系统架构设计和软件架构设计两个子步骤。经过架构师的良好分析，车辆功能(业务逻辑/业务过程)将结合实际实现情况，按不同业务领域完成解耦，并分解得到候选服务组件。后续，经过详细且不断迭代的设计，在候选服务的基础上，最终会产出面向服务(SOA)的软件架构。

图3 面向服务的分析与设计是服务架构开发的核心环节

接下来本文将围绕这5个子步骤对面向服务的分析与设计过程进行介绍。

如图4所示，整个SOA架构模型分为业务过程层，服务接口层和应用程序层三部分。SOA业务过程层专注于业务逻辑的分析；服务接口层聚焦于候选服务的设计和分析；应用程序层则体现面向服务的系统架构和软件架构设计。

系统需求分析聚焦SOA架构的最上层——业务层。概括来说，需求分析指的是设计和充分理解在用户具体使用场景下的真实业务过程，为后续抽象和封装服务提供充足的语境信息。

图4 需求分析聚焦SOA架构业务过程层

2. 系统功能分析

如图5所示，系统功能分析搭建起了SOA架构的业务层和服务层之间的桥梁，其过程就是从第一步系统需求分析的产物——业务过程和系统用例，向服务过渡的过程，目的是得出构成候选服务的服务操作（operation）。系统功能分析具体可描述为：设计用例的实现场景步骤，对系统用例逐个进行分析细化，描述系统如何与参与者（actor）一起实现每个用例，从而得到系统与参与者、与外部系统的界限及信息交互，最终得出对系统的功能要求，这些功能要求直接作为候选服务操作（business service operation candidates）。

图5 系统功能分析：从业务过程到服务

3. 候选服务分析

候选服务分析聚焦SOA架构的中间层——服务接口层。候选服务分析的目的是对业务逻辑进行抽象和封装，从业务角度寻找候选服务（Service Candidate）。值得强调的是，分析候选服务需要跳出特定功能开发，从架构角度强调业务的重用性(reusable)、自主性(autonomous)以及组合扩展性(composable)等特点，特别考虑候选服务在企业业务范围内潜在的重用可能，充分发挥SOA设计理念的优势，而不是仅仅作为技术实现方式(图6)。

图6 候选服务分析聚焦SOA架构的服务接口层4. 系统架构设计

系统架构设计的目的是设计和得到服务到架构要素的映射，以及要素间服务调用关系。下图中蓝色小圆圈代表分析得到的服务，通过系统架构设计，被映射至不同的架构要素( Platform A~C)(图7)。在这里，架构要素对应汽车上搭载不同控制器平台(Platform)。

图7 系统架构设计：服务与系统要素的映射

4. 软件架构设计

软件架构设计的目的是设计和得到服务（service）到服务组件（Service Component）的映射关系，过程与系统架构的设计过程类似，但需要将关注点转移到控制器内部。

在图8，SOA架构中，软件架构设计的行为发生在蓝色阴影区。软件架构的设计受到诸多因素的限制(以太网通讯Port口资源，客户具体用例场景的迭代变更等等)。总体设计思想上，高内聚，低耦合仍是设计的通用原则和架构评价的关键指标。额外需要强调的，应对智能网联软件需求迭代多变的特性，在SOA服务架构的设计中，还需强调重用性和扩展性，充分的灵活度才能以最小的软件变更应对大量的需求输入。

图9为一示意图，表达了针对某一服务Service A，有一个服务提供组件(Service Component)提供A服务，有三个服务消费组件消费服务A。

图8 软件架构设计

图9 服务与应用程序的映射

“分析和设计面向服务的架构”、“实现和部署面向服务的软件”是有效开发SOA汽车软件的关键环节， “分析和设计服务架构”的过程是从客户用例场景/需求到SOA软件架构产出的分析过程。

联合电子：面向服务架构（SOA）的汽车软件三部曲

已剪辑自: http://www.uml.org.cn/soa/2021060312.asp

**编辑推荐:**本文讨论SOA汽车软件的开发方法，并付诸实践：第一部分提出一种SOA汽车软件分层模型；第二部分基于分层模型，介绍两种SOA汽车软件开发方法。 本文来自于联合电子，由火龙果软件Anna编辑、推荐。

随着汽车智能化、网联化、共享化的趋势，终端用户对车辆功能的预期也悄然发生着改变，汽车在实现高等级自动驾驶/辅助驾驶功能的同时，也更趋向于提升用户体验，例如满足快速的功能更新和升级，可以提供个性化、人性化、差异化的功能与服务等。

面向服务的软件架构(Service-Oriented Architecture)正为未来的车辆软件服务提供良好的解决方案。不同于传统汽车电子电气架构中面向信号的架构，面向服务的软件架构(SOA)通过标准化的服务接口，松耦合的服务机制以及可组合扩展的服务特性，结合未来以高性能计算平台——域控制器——为核心的集中化电子电气架构，将成为未来汽车领域“软件驱动创新”的技术基础。

第一部：面向服务架构(SOA)的汽车软件及其开发方法

一. 为什么要引入SOA汽车软件” />

图2 面向服务的架构(Service-Oriented Architecture)

二. 如何有效的开发SOA汽车软件？

对于汽车行业而言，SOA是一套新引入的技术，需要一套有效的流程、方法和工具，用以解决如下三个问题：1) 如何分析和设计服务架构，2) 如何建模和记录服务架构，3)如何部署和实现面向服务的软件。

  1. 如何分析和设计面向服务的架构?

“分析和设计服务架构”的过程是从客户需求到SOA软件架构产出的分析过程，相对于传统汽车软件开发采用的基于功能分解的面向过程分析方法，“用例驱动的开发方法”和“面向服务架构的设计方法”是SOA软件架构开发的两个主要特点。

用例(Use Case)驱动的开发方法(图3)指从用户的角度而非开发人员的角度考虑功能需求和系统实现，重视从系统外部观察对系统的使用。由用例驱动的开发活动，可以建立需求和系统功能之间清晰的追溯关系，更好的应对智能网联产品需求的快速迭代更新。

面向服务的分析方法(图4)则是以业务为中心，在由用例分析得到系统功能需求的基础上，对业务逻辑进行抽象和封装，从业务角度寻找候选服务（Service Candidate），从架构角度强调服务的重用性(reusable)、自主性(autonomous)以及组合扩展性(composable)特点，充分发挥SOA设计理念的优势，而不是仅仅作为技术实现方式。

图3 用例驱动的开发方法

图4 面向服务的分析方法

  1. 如何建模和记录面向服务的架构” />

    图5 SysML语言，Rhapsody工具和ARC42开发模板

    1. 如何部署和实现面向服务的软件

    “部署和实现面向服务架构的软件”的过程是以SOA软件架构为设计输入，最终开发实现出软件产品的工作过程(图6)。主要包括 1)对服务接口行为的开发和实现，完成服务接口与服务主体逻辑的绑定；2) 针对目标运行环境，完成对服务接口参数，服务主体运行参数的配置；3)服务接口与应用程序策略逻辑的集成编译。

    AUTOSAR Adaptive 组件封装了SOA软件底层的通讯细节(包括SOME/IP协议，IPC等)，同时提供代理(Proxy)-骨架(Skeleton)模型，该模型以C++面向对象语言描述，方便上层应用开发人员调用标准服务接口(API)进行开发。Application Design Model是该模型另一种可配置的呈现，开发人员通过使用相应的配置工具对Application Design Model进行描述和配置，即可实现基于SOA服务架构的软件落地和部署。联合电子使用AUTOSAR Adaptive组件完成SOA服务架构软件的开发(图7)：

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Jn4NYYhl-1660664666998)(http://www.uml.org.cn/soa/images/20210603126.png)]

    图6 部署和实现面向服务的软件

    图7 应用软件设计模型

    三. SOA汽车软件创新平台

    联合电子开发的域控制器XCU ，提供了部署SOA汽车软件的平台。在硬件方面，XCU具备高算力处理器芯片和多路车规级以太网通道；在软件方面，XCU搭载POSIX操作系统和AUTOSAR Adaptive平台。

    根据SOA软件开发方法，可从两个切入点开展SOA汽车软件平台的开发。

    1)自下至上，从车辆基础功能/信号出发，将已有的应用功能逻辑/信号(eg:车辆车速信息)抽象或封装成服务组件，这类组件被称为基础服务层(Basic/Platform Service Layer)组件，具有最高的可复用性和可组合性，这些组件将为上层(业务服务层Business Service Layer)的服务组件提供最基础的支持。

    2)自上而下，从整车业务逻辑和用例出发，结合各领域的核心业务知识，设计业务服务层(Business Service Layer)的服务组件；同时，遵循服务组件的复用性和自主性等原则，向下设计规划基础服务层(Basic/Platform Service Layer)的服务组件(图8)。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EDrD5miC-1660664666999)(http://www.uml.org.cn/soa/images/20210603128.webp.jpg)]

    图8 基于域控制器(XCU)的SOA服务架构

    四. SOA架构的核心要素与优势

    SOA作为一种面向服务的架构，是一种设计思想和方法论。在SOA架构中，服务是最核心的抽象手段和系统最基础的描述单元。

    每个服务组件具备独立的功能，且可被复用；服务组件之间的接口遵循统一标准，可互相访问，可组合扩展。业务过程则是带有状态和服务调度策略的服务组件的组合与扩展(图1)。

    通过SOA架构，可整合规划OEM在不同操作系统，硬件平台上(控制器)上的业务功能，实现对功能的快速迭代和重组，应对灵活多变的智能网联趋势下的业务需求。

    图9：SOA架构模型

    结合未来汽车域导向型电子电气架构(Domain-Oriented)和区域导向型电子电气架构(Zone-Oriented)，应用SOA架构可实现业务过程(功能)的快速迭代与灵活重组，为智能网联趋势下的软件个性化与创新需求提供了良好的平台性解决方案。SOA架构应用于汽车新电子电气架构下的优势(图2):

    车辆功能软件实现软硬分离

    由于服务组件接口“标准可访问”，且描述方式独立于硬件平台和操作系统，因此组件功能可脱离硬件平台任意部署移动，对于算力有要求的复杂功能组件可向具备高带宽大算力的域控制器移动。

    车辆功能可被大范围复用

    一些使用频度很高且基础的功能可作为基础服务组件先被开发，由于服务组件的独立性以及接口的标准可访问，基础服务开发完成后可向服务中间件注册，并供所有电子电气架构中的控制器订阅使用。

    车辆功能在SOP后可新增(扩展)

    “小”的基础服务可组合成为“大”服务，“大”服务可进一步组合扩展并最终构建出新的业务过程，实现OEM的业务目标。结合OTA技术，用户可在车辆使用期限里，订阅一个类似，“预测性能量管理”的新功能并安装于域控制器上，新功能的业务逻辑依赖于一些已有的服务组件(eg:预测性能量管理依赖于能量管理策略，地图预测信息等基础服务)。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9gmoYTjn-1660664666999)(http://www.uml.org.cn/soa/images/202106031210.png)]

    图10 新汽车电子电气架构中的SOA架构应用

    第二部：面向服务架构（SOA）的汽车软件分析和设计

    面向服务架构的开发过程从整体上可以概括为6个步骤，分别是：面向服务分析、面向服务设计、服务开发、服务测试、服务部署和服务权限管理，如图11所示。其中，分析和设计面向服务的架构是开发SOA软件的开端，也是判断系统是否基于SOA架构的最重要且核心的环节。

    联合电子对分析和设计面向服务架构汽车软件的具体流程与方法进行了探索，将面向服务的分析分解为系统需求分析、系统功能分析、候选服务分析三个子步骤，将面向服务的设计分解为系统架构设计和软件架构设计两个子步骤。经过架构师的良好分析，车辆功能(业务逻辑/业务过程)将结合实际实现情况，按不同业务领域完成解耦，并分解得到候选服务组件。后续，经过详细且不断迭代的设计，在候选服务的基础上，最终会产出面向服务(SOA)的软件架构。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-S9vA4JEL-1660664666999)(http://www.uml.org.cn/soa/images/202106031211.png)]

    图11 面向服务的分析与设计是服务架构开发的核心环节

    接下来本文将围绕这5个子步骤对面向服务的分析与设计过程进行介绍。

    \1. 系统需求分析

    如图12所示，整个SOA架构模型分为业务过程层，服务接口层和应用程序层三部分。SOA业务过程层专注于业务逻辑的分析；服务接口层聚焦于候选服务的设计和分析；应用程序层则体现面向服务的系统架构和软件架构设计。

    系统需求分析聚焦SOA架构的最上层——业务层。概括来说，需求分析指的是设计和充分理解在用户具体使用场景下的真实业务过程，为后续抽象和封装服务提供充足的语境信息。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ISLki0sT-1660664667000)(http://www.uml.org.cn/soa/images/202106031212.png)]

    图12 需求分析聚焦SOA架构业务过程层

    \2. 系统功能分析

    如图13所示，系统功能分析搭建起了SOA架构的业务层和服务层之间的桥梁，其过程就是从第一步系统需求分析的产物——业务过程和系统用例，向服务过渡的过程，目的是得出构成候选服务的服务操作（operation）。系统功能分析具体可描述为：设计用例的实现场景步骤，对系统用例逐个进行分析细化，描述系统如何与参与者（actor）一起实现每个用例，从而得到系统与参与者、与外部系统的界限及信息交互，最终得出对系统的功能要求，这些功能要求直接作为候选服务操作（business service operation candidates）。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HzPwS6wO-1660664667000)(http://www.uml.org.cn/soa/images/202106031213.png)]

    图13 系统功能分析：从业务过程到服务

    \3. 候选服务分析

    候选服务分析聚焦SOA架构的中间层——服务接口层。候选服务分析的目的是对业务逻辑进行抽象和封装，从业务角度寻找候选服务（Service Candidate）。值得强调的是，分析候选服务需要跳出特定功能开发，从架构角度强调业务的重用性(reusable)、自主性(autonomous)以及组合扩展性(composable)等特点，特别考虑候选服务在企业业务范围内潜在的重用可能，充分发挥SOA设计理念的优势，而不是仅仅作为技术实现方式(图14)。

    图14 候选服务分析聚焦SOA架构的服务接口层

    \4. 系统架构设计

    系统架构设计的目的是设计和得到服务到架构要素的映射，以及要素间服务调用关系。下图中蓝色小圆圈代表分析得到的服务，通过系统架构设计，被映射至不同的架构要素( Platform A~C)(图15)。在这里，架构要素对应汽车上搭载不同控制器平台(Platform)。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Atewb2Vx-1660664667001)(http://www.uml.org.cn/soa/images/202106031215.webp.jpg)]

    图15 系统架构设计：服务与系统要素的映射

    \5. 软件架构设计

    软件架构设计的目的是设计和得到服务（service）到服务组件（Service Component）的映射关系，过程与系统架构的设计过程类似，但需要将关注点转移到控制器内部。

    在图16，SOA架构中，软件架构设计的行为发生在蓝色阴影区。软件架构的设计受到诸多因素的限制(以太网通讯Port口资源，客户具体用例场景的迭代变更等等)。总体设计思想上，高内聚，低耦合仍是设计的通用原则和架构评价的关键指标。额外需要强调的，应对智能网联软件需求迭代多变的特性，在SOA服务架构的设计中，还需强调重用性和扩展性，充分的灵活度才能以最小的软件变更应对大量的需求输入。

    图17为一示意图，表达了针对某一服务Service A，有一个服务提供组件(Service Component)提供A服务，有三个服务消费组件消费服务A。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JH8tHduY-1660664667001)(http://www.uml.org.cn/soa/images/202106031216.webp.jpg)]

    软件架构设计和 服务与应用程序的映射

    结语

    “分析和设计面向服务的架构”、“实现和部署面向服务的软件”是有效开发SOA汽车软件的关键环节， “分析和设计服务架构”的过程是从客户用例场景/需求到SOA软件架构产出的分析过程。

    联合电子认为，相对于传统汽车软件开发采用的基于功能分解的面向过程的分析方法，“用例驱动的开发方法”和“面向服务架构的设计方法”是SOA软件架构开发的两个主要特点。

    联合电子具备相关项目经验，可以帮助具备业务逻辑的厂商(OEM/第三方)完成基于服务的用例分析和架构设计工作，并最终协助客户输出面向服务的软件架构。

    第三部：面向服务架构（SOA）的汽车软件实现和部署

    根据SOA架构层级模型(图18)，业务逻辑经过面向服务架构(SOA)的软件分析和设计过程后，被分解为单个服务并绑定相应的可执行软件单元。以服务软件架构为输入，汽车服务软件的实现和部署工作主要在服务组件层(Service Components)完成(图1红色箭头)。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wQakfHJQ-1660664667001)(http://www.uml.org.cn/soa/images/202106031217.png)]

    图 18 SOA 层级架构模型

    01 满足 SOA 架构的服务组件架构 (Service-Component-Architecture)

    针对服务组件，SOA定义了服务组件的架构模型(SCA)(图19)，在SCA的框架下，服务组件内部被分为业务逻辑(Service)与基础设施逻辑(Interface和Message)两部分，并互相解耦：

    服务软件单元(Service)：业务/功能逻辑，不关心操作系统和编程语言，可由熟悉业务逻辑的相关方开发

    接口(Interface)：决定对外提供哪些服务以及自身服务依赖哪些服务，不关心操作系统和编程语言，可由SOA架构设计方完成开发和部署

    消息(Message)：接口数据的通讯链路/环境绑定，不关心操作系统和编程语言，可由SOA架构设计方完成开发和部署

    整个服务组件层的工作是对服务组件进行规范型描述，描述内容主要包含两个部分:

    服务组件架构模型SCA的配置描述

    服务组件内部业务逻辑和基础设施逻辑的集成

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UfTJywTf-1660664667001)(http://www.uml.org.cn/soa/images/202106031218.png)]

    图19 SOA服务组件架构模型(SCA)

    02 服务组件架构SCA的配置描述

    通过SCA架构模型，每个服务软件单元(Service)以标准的接口形式(Interface)向消费方提供服务内容，以统一的通讯协议传递序列化消息(Message)。对于SOA架构设计和应用人员，需要通过工具配置SCA架构模型中的参数，使其与服务管理组件一同实现SOA软件的部署和运作。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zAcMMfKr-1660664667002)(http://www.uml.org.cn/soa/images/202106031219.webp.jpg)]

    图20 SCA架构模型中的配置信息

    SCA架构模型中的主要元素分为“服务接口”和“服务实现”两大类。其中，“服务接口描述”包含服务软件单元(Services)，组件接口(Interface)和消息通讯(Message)；“服务实现”则包括通讯协议绑定(Binding)和服务端口信息等(Endpoint)(图20)。

    WebService的SCA架构模型配置描述

    以IT行业SOA封装使用较为广泛的WebService为例，其对SCA架构模型的描述遵从如下标准协议:

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fhtfGy1B-1660664667002)(http://www.uml.org.cn/soa/images/202106031220.png)]

    表1 SCA架构模型中的配置信息

    在IBM公司发布的SOA系统解决方案- 企业服务总线(Enterprise-Service-Bus)中提供了WebSphere Integration Developer开发环境，该环境支持配置生成符合WSDL规范的服务组件描述文档。

    汽车软件的SCA架构模型配置描述

    在汽车软件领域，当前，联合电子采用AUTOSAR Adaptive组织提供的模型描述规范。AUTOSAR Adaptive组织对SCA架构模型的描述遵循如下标准:

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IDSmzJ7n-1660664667002)(http://www.uml.org.cn/soa/images/202106031221.webp.jpg)]

    表2 SCA架构模型中的配置信息

    03 汽车SOA软件的实现方案

    如上文所述，汽车软件领域，联合电子遵循AUTOSAR Adaptive标准来完成SOA中间件的部署和应用，AUTOSAR Adaptive组件采用经典的代理(Proxy)-框架(Skeleton)模式来完成SCA架构模型的描述(如图21)。

    图21 Proxy(stub)/Skeleton架构模式

    这种模式将原本直接交互的调用者(Client)与被调用者(Server)分离，由代理负责传递信息来完成调用，client和server不需要处理通信层详细信息。同时，AUTOSAR Adaptive厂商基于C++语言具体实现代理-框架模式，确保应用服务开发人员可以灵活配置自定义的服务接口，并结合对应工具生成SCA架构模型代码(.cpp/.cc)和配置文件(.json)。具体的，这些代码：

    封装了SOME-IP协议栈和底层通讯细节(Middleware Transport Layer)

    提供了相应的服务虚接口(virtual function)

    通过1)，服务组件开发人员不必再关心服务Message对应的协议如何实现；通过2)，服务组件开发人员基于C++的语言特性，可继承(inherit)虚接口并覆写(override)虚接口的具体实现(函数体)。该机制保证了“基础设施逻辑”和“业务(功能)逻辑”的解耦，服务内部业务逻辑的改动不影响服务组件向外的接口提供。

    04 SOA服务组件实现和部署的具体步骤

    SOA服务组件“实现和部署”的整个过程以面向服务(SOA)的软件架构为输入，内容上除完成第二章提到的“基础设施逻辑”配置工作外，还需将业务(功能)逻辑与基础设施逻辑集成，最终编译成可执行的服务组件单元(Service Component)(图22)。

    图22 服务组件单元(Service Component)

    如第一章中对服务组件的SCA描述，整体服务组件(Service Component)由服务单元(Service)提供的“业务逻辑”和适配目标系统环境相关的“基础设施逻辑”两部分组成。在开发过程中，这两部分是解耦的，可同时进行的，且软件形态是灵活的。

    服务单元(Service)的逻辑可以是源码或被封装为SDK形式，且不关心具体的编程语言；基础设施逻辑 (Interface和Message) 则以C++的形态编码，与服务管理中间件一起确保服务的动态响应性和服务自身的可扩展性，其软件形态同样可以是源码或SDK形式提供。

    在流程上方法论上，”实现和部署”工作主要分为服务组件接口设计，服务组件集成实现和安装部署三个步骤：

    组件接口设计阶段: 联合电子编写arxml完成对服务组件SCA中“基础设施逻辑”的配置开发，并经由AUTOSAR Adaptive中间件供应商提供的代码框架和生成器(Generator)，最终得到相关的配置文件(.json)和源代码(.cc/.cpp)；对“服务单元逻辑”，联合电子可同步基于建模工具进行开发；

    组件集成实现阶段: 联合电子编写APP框架，完成“服务单元逻辑”与“基础设施逻辑”的软件集成工作；

    组件安装部署阶段: 联合电子编写编译和安装脚本，完成源码的编译链接和可执行文件(App)的安装，同时，对APP安装部署权限和系统环境做适配调整。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NMmvc9sL-1660664667003)(http://www.uml.org.cn/soa/images/202106031224.png)]

    “分析和设计面向服务的架构”、“实现和部署面向服务的软件”是有效开发SOA汽车软件的关键环节，“实现和部署面向服务软件”的过程是SOA软件可以“落地”不可或缺的环节。

    汽车SOA架构

    已剪辑自: https://zhuanlan.zhihu.com/p/360385024

    随着汽车新四化的趋势，现在新的汽车消费群体对车的要求也已经发生了巨大的改变，车在全面实现网联，自动驾驶，数据驱动的同时，也更趋向于直接触达用户，提升体验，服务，用户的个性化需求。同时高算力芯片，感知技术，数据智能等科技产品的引入，也需要车企突破传统的电子电气架构的枷锁。
    在上一篇文章《整车电子电器的集中式发展》中，我介绍了整车电子电气架构演进的趋势和想法。本文我集中介绍一下在这种趋势下，SOA架构在整车架构设计时中核心优势。

    SOA是什么

    SOA(Service-Oriented Architecture) 面向服务的架构
    SOA是一种软件架构，同时一种软件设计的思想，其实已经在IT领域有了很多年的发展和应用了。在SOA架构中，服务是最核心的抽象手段和系统最基础的单元。每个服务组件具备独立的功能；服务组件之间的接口遵循统一的标准，可互相访问，可组合扩展。业务过程则过程则是带有状态和服务调度策略的服务组件的组合和扩展，如下图所示。它具有，松耦合、可复用、高内聚的特点，请参考下图。

    SOA Benefits

    SOA将跨域跨ECU交互由“基于信号的通讯”变为“基于服务的通讯”。
    • 应用服务化，使“全车智能”成为可能
    服务化，各个域将自己的能力提供出来，在权限允许的情况下，供大家自由使用。
    • 服务的灵活部署
    SOA的一个基础，就是“服务发现”机制，即给每个服务分配一个“全局名称”，通过这个名称就可以直接找到对应的服务。
    • 软件更新/升级更快速
    一个功能的改变可能只需要更新/升级一个服务。
    • 服务高内聚，软件易重用
    一个服务往往只关注“一件事”做好。这件事需要从业务的角度进行梳理。

    SOA == Some/IP” />

    特点：
    Remote Procedure Call(RPC)，远程服务调用
    Service Discovery(SD)，服务发现
    Publish/Subscribe(Pub/Sub)，发布订阅
    Segmentation of UDP message , UDP拆组包以支持大数据传输（>1UDP Packet）

    在整车电子电气架构中，某一个ECU有时会需要调用其他ECU上的一个服务，这是他们就分别扮演了Client和Server的角色，而Some/IP就是实现这种远程服务调用的接口，请参考下图

    服务接口的主要分类

    **Method：**一种远程过程调用，采用Request-Response机制进行通信，由Client发送远程过程调用请求Request，用于请求相关数据或者请求执行相关操作，Server收到Request，根据内容做一些操作之后，通过Response对Client的Request做出一些反馈。Method是一种可靠传输的服务接口，需要关系Request是否被送达。
    **Event：**订阅-发布机制是控制事件组的交互，之后事件组是以单个Event报文进行就交互，从而向Client发送相关数据。Event是一种单向传输，无法保证数据是否被准确送达。
    **Field：**Field关联三种服务接口，以组合的形式来呈现，三者对同一个数据做相关联的操作。Getter->Client主动获取相关操作的当前数据，该服务接口Request不携带任何数据
    Setter->Client主动设置相关操作的数据，同时Server要将Client设置的数据通过Response反馈给Client，以便Client确认设置的数据是否成功。Notification->通信行为和Event极为类似，也遵循订阅-发布机制，以事件组的形式来订阅，但所发布的数据和Getter/Setter是同一套。
    三个方法的过程请参考下图

    基于总线 VS SOA

    • 当前车企整车软件大多是基于AUTOSAR架构开发的，它是一种面向信号的架构，一个模块会不停的在总线上发送信息给另一个控制器。
    • SOA是面向服务的架构，通过标准化的服务接口，松耦合的服务机制及可扩展性的服务特性，结合未来以高性能计算平台“域控制器”为核心的集中化电子电器架构，将成为未来汽车领域“软件定义汽车”，“科技驱动创新”“数据驱动服务”的技术基础，对比图如下。

    SOA中的角色

    **服务（Service）:

    **提供某种功能的函数或方法，是一个离散的功能单元，可以远程访问并独立执行和更新。
    **服务接口（Service Interface）：

    **能够被外界模块调用的函数名称或一个封装AP。
    **服务提供者（Service Provider）：

    **实现服务功能（包含控制算法，功能逻辑等）的一方。
    **服务使用者（Service Consumer）:

    **使用服务接口，调用服务的一方。
    关系图如下。

    服务颗粒度如下图：

    SOA场景举例

    智能汽车中，大量的功能需要ECU间的协调功率来实现，当前ECU间基于信号的通讯会变得异常复杂，且不具备灵活性和扩展性，微小的功能改动都会引起整车通讯矩阵的改动，下图示例请参考。

    传统CAN通信

    SOA引入到汽车软件设计中，车辆功能被以面向服务的设计理念架构设计成不同的服务组件，SOA中每个服务都具有唯一的身份标识，可以完成自身的发布，对其他服务的订阅，与其他服务的通讯。由此，SOA很好的解决了传统架构中因个别功能增加/变更而导致整个通讯矩阵，上下游模块都要跟随变更的问题，下图示例请参考。

    基于SOA通信

    哪些传统架构中的服务和信号可以通过SOA来实现

    理论上所以传统架构中的服务和信号都可以通过SOA来实现，但是目前传统的CAN，LIN等信号交互方式，网络传输稳定，问题和分析简单，工具链也更完善。因此一些跟驾驶安全相关的服务和信号还是建议使用传统的通信方式，也是目前已经规划SOA架构的车企没有完全用SOA取代传统架构的原因，下图请参考。

    随着SOA更多车企引入SOA的架构方案，相信未来SOA在整车电子电气架构上的开发和应用会越来越完善。

    以上希望能够帮助到大家，也希望有专家来指导指正。