《车载SOA软件架构技术规范1.0》解读2：车载SOA软件架构设计规范.docVIP

《车载SOA软件架构技术规范1.0》解读2：车载SOA软件架构设计规范 背景： 本文节选自《车载SOA软件架构技术规范1.0》，该规范是由AUTOSEMO撰写的首个车载SOA软件架构技术规范，也是首个面向汽车行业SOA软件架构的理论体系。近期，AUTOSEMO将组织针对本规范的官方解读，有兴趣的朋友可以关注“AUTOSEMO”，了解更多信息。 继上一篇文章《SOA架构技术概述及技术规范现状》，介绍了规范的前面两个章节，本篇将介绍第三章。 01 车载SOA软件架构开发流程 1.1 SOA设计方法 面向服务的架构转换应通过以下两种主要方法实现，如下图所示。 自下而上方法：应遵循此方法，以改造现有车辆程序和平台上实施的现有功能或系统的EE架构（逆向工程）。由于国内OEM的现有功能不具备逻辑功能架构，因此我们建议将网络拓扑、网络通信、ECUs平台架构、功能需求和用例场景作为分析SOA转换的起点。但是如果特性很复杂，那么仍然有必要使用逻辑功能架构来定义高质量和完整性的SOA。 自顶向下的方法：对于引入车辆程序和平台的新特性或系统，基于SOA的EE架构应遵循这种方法。这种方法需要给定特性或系统的需求和用例以及逻辑功能架构作为输入。 在上述两种方法中，软件平台架构师需要考虑应提供的域级公共或基础服务， 并考虑需要支持的子系统和功能的列表。当软件架构师在单个特性或系统级别定义服务和契约时，如果服务具有公共功能并且在平台级别不存在，软件架构师需要与软件平台架构师讨论如何定义相同的服务和契约。 1.2 服务类型 服务应定义为以下四个不同级别： 硬件抽象服务：基于ECUs功能和硬件外围设备（传感器和执行器），定义硬件抽象服务。这些服务应该在软件平台级别提供。 平台核心服务：所有跨应用程序集群和域的公共服务都需要在软件平台级别定义和提供。 域核心服务：在一个应用集群中，跨不同应用程序的公共服务应定义为域核心服务。 应用程序服务：特定于系统的每个应用程序或功能的服务，需要定义为应用程序服务。 02 车载SOA软件架构设计 根据基于模型的系统工程方法和以下面向服务架构建模语言(SOAML)，提供了用于面向服务和软件架构建模的各种元模型的详细信息。SOA和软件层元模型可以大致分为两类：核心建模（数据）和图表（可视化）。 2.1 核心模型设计 这些是为每个特性或系统建模SOA和软件体系结构的核心。 服务：服务可以通过定义的接口提供可用的功能。每个服务都有一个用于服务注册和发现的唯一ID。服务使用者应使用此ID识别服务，并根据define接口使用功能。尽管服务定义不一定要有使用者。 服务提供者：服务提供者是具有提供服务功能的特定角色的服务的实例。服务提供商根据定义的服务接口（合同）提供服务。 服务使用者：服务使用者是具有使用服务功能的特定角色的服务的实例。服务使用者需要确保从提供者获得定义的服务接口（契约）。 服务端口：服务端口是服务提供者或使用者之间相互通信的接口点。 服务接口：服务接口是服务提供者和使用者之间数据交换的定义。它定义了向使用者公开的服务的属性。服务接口应包括以下内容： 使用getter和setter将字段转换为属性 方法（请求和响应） Fire-and-Forget方法（请求无需响应） 事件和事件组 方法－请求和响应：这是服务接口的一部分，在客户端或服务器中调用方法并期望得到确认。 Fire-and-Forget方法：这是服务接口的一部分，在服务接口中，客户机在不等待服务器确认的情况下调用方法。 事件：这是服务接口的一部分，服务角色在其中更新数据或传递操作。服务使用者可以订阅事件或事件组。 属性或字段：这是表示服务服务器中某些数据的服务接口的一部分。服务器应通过公开getter和setter方法向使用者提供对该数据的访问。 参数：它定义一个方法的输入或返回参数（请求／响应和fire-and-forget方法）。 面向服务的体系结构：每个特性或系统的SOA包括具有id的服务定义、服务角色（提供者和使用者）、服务器接口定义以及与定义的服务接口相关的相互接口的服务角色。 组合：用于按层次结构组织软件组件。 应用软件组件(SWC)：它表示在软件体系结构层具有足够粒度的给定功能。它应该足够细化，可以部署在单个硬件组件上。SWC应为AUTOSAR经典或自适应或非AUTOSAR软件组件。如果是AUTOSAR经典或自适应，则必须按照标准AUTOSAR定义遵循类型－原型－实例结构。 软件端口：软件端口存在于软件组件上，表示操作（如果是客户端服务通信）或数据元素（如果是发送方－接收方通信），提供或订阅的数据。发送方－接收方接口或客户端服务接口被分配给软件端口。 软件组装连接器：通过使用软件组装连接器（软件级数据流）连接软件端口，使软件组件相互连接。 客户机服务接