#百人创作先锋团#《车载SOA软件架构技术规范1.0》解读2

发布于 2023-2-8 15:17
浏览
1收藏

背景:

本文节选自《车载SOA软件架构技术规范1.0》,该规范是由AUTOSEMO撰写的首个车载SOA软件架构技术规范,也是首个面向汽车行业SOA软件架构的理论体系。近期,AUTOSEMO将组织针对本规范的官方解读,有兴趣的朋友可以关注“AUTOSEMO”公众号,了解更多信息。

继上一篇文章​​《SOA架构技术概述及技术规范现状​​》,介绍了规范的前面两个章节,本篇将介绍第三章。

01 车载SOA软件架构开发流程

1.1 SOA设计方法

面向服务的架构转换应通过以下两种主要方法实现,如下图所示。

#百人创作先锋团#《车载SOA软件架构技术规范1.0》解读2-汽车开发者社区

自下而上方法:应遵循此方法,以改造现有车辆程序和平台上实施的现有功能或系统的EE架构(逆向工程)。由于国内OEM的现有功能不具备逻辑功能架构,因此我们建议将网络拓扑、网络通信、ECUs平台架构、功能需求和用例场景作为分析SOA转换的起点。但是如果特性很复杂,那么仍然有必要使用逻辑功能架构来定义高质量和完整性的SOA。


自顶向下的方法:对于引入车辆程序和平台的新特性或系统,基于SOA的EE架构应遵循这种方法。这种方法需要给定特性或系统的需求和用例以及逻辑功能架构作为输入。


在上述两种方法中,软件平台架构师需要考虑应提供的域级公共或基础服务,

并考虑需要支持的子系统和功能的列表。当软件架构师在单个特性或系统级别定义服务和契约时,如果服务具有公共功能并且在平台级别不存在,软件架构师需要与软件平台架构师讨论如何定义相同的服务和契约。

1.2 服务类型

服务应定义为以下四个不同级别:


硬件抽象服务:基于ECUs功能和硬件外围设备(传感器和执行器),定义硬件抽象服务。这些服务应该在软件平台级别提供。


平台核心服务:所有跨应用程序集群和域的公共服务都需要在软件平台级别定义和提供。


域核心服务:在一个应用集群中,跨不同应用程序的公共服务应定义为域核心服务。


应用程序服务:特定于系统的每个应用程序或功能的服务,需要定义为应用程序服务。

#百人创作先锋团#《车载SOA软件架构技术规范1.0》解读2-汽车开发者社区

02 车载SOA软件架构设计

根据基于模型的系统工程方法和以下面向服务架构建模语言(SOAML),提供了用于面向服务和软件架构建模的各种元模型的详细信息。SOA和软件层元模型可以大致分为两类:核心建模(数据)和图表(可视化)。

#百人创作先锋团#《车载SOA软件架构技术规范1.0》解读2-汽车开发者社区

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定义遵循类型-原型-实例结构。


软件端口:软件端口存在于软件组件上,表示操作(如果是客户端服务通信)或数据元素(如果是发送方-接收方通信),提供或订阅的数据。发送方-接收方接口或客户端服务接口被分配给软件端口。


软件组装连接器:通过使用软件组装连接器(软件级数据流)连接软件端口,使软件组件相互连接。


客户机服务接口、操作和参数:如果软件端口以客户机和服务器模式交换数据,则分配给它们的接口称为客户机服务接口。这个接口需要包括每个操作的操作和参数(输入和返回)。


发送方-接收方接口和数据元素:如果软件端口以双向模式交换数据,则分配的接口称为发送方-接收方接口。此接口需要包括数据元素(表示交换的数据)和数据类型分配。数据类型应为应用数据类型和实现数据类型。应根据这些数据类型定义计算方法。

2.2 SOA设计-图表设计

SOA设计和软件架构(architecture)数据应以表格格式或图表形式可视化。应使用定制的表格格式来可视化SOA设计数据和软件架构定义。


面向服务的体系结构图(SOAD):该图应可视化给定功能或服务、服务角色(服务提供者和服务使用者)、服务端口和服务接口。下面是SOA图的示例视图:

#百人创作先锋团#《车载SOA软件架构技术规范1.0》解读2-汽车开发者社区


软件架构图(SWAD):一旦SOA定义完成,就应该定义软件组件方面的服务部署。此图显示了用于数据交换的软件组件、软件端口及其之间的连接(软件程、序集连接器)。还应显示每个软件组件上部署的逻辑功能。下面是软件架构图示例:

03 车载SOA软件架构服务设计

服务定义


服务使用SOME/IP总线向客户端提供一些功能。所提供的功能既可以作为请求消息公开,也可以作为发送消息公开。


服务集群划分


服务是基于子系统重新划分群集的。


服务描述模板


服务描述必须包含以下信息:


  • 服务描述:服务目的的简短描述。


  • 消息类型:方法或事件。


  • 讯息名称:讯息名称。


  • 消息描述:消息用途的简短描述。


  • 消息输入参数:此规范类型使用的输入参数的完整列表。


  • 返回参数:此规范类型使用的返回参数的完整列表。


此外,必须描述枚举和自定义类型。


文章转载自公众号:汽车电子与软件

标签
1
收藏 1
回复
举报
回复
相关推荐