车载SOA软件架构设计
根据基于模型的系统⼯程⽅法和以下⾯向服务架构的建模语⾔(SOAML)，提供了⽤于⾯向服务和软件架构建模的各种元模型的详细信息。SOA和软件层元模型⼤致分为两类：核⼼建模(数据)和图表(可视化)。
SOA设计-核⼼模型设计
这些是为每个特性或系统建模SOA和软件体系结构的核⼼。
服务：服务可以通过定义的接⼝提供可⽤的功能。每个服务都有⼀个⽤于服务注册和发现的唯⼀ID。服务使⽤者应使⽤此ID识别服务，并根据定义的接⼝使⽤功能，尽管服务定义不⼀定要有使⽤者。服务的类型包括：
•硬件抽象服务：基于ECUs功能和硬件外围设备(例如传感器、执⾏器)，定义硬件抽象服务。这些服务应该在软件平台级别提供。
•平台核⼼服务：所有夸应⽤程序集和域的公共服务都需要在软件平台级别定义和提供。
•域核⼼服务：在⼀个应⽤集中，跨不同应⽤层序的公共服务定义为域核⼼服务。
•应⽤程序服务：特定于系统的每个应⽤程序或功能的服务，需要定义为应⽤程序服务。
服务提供者：服务提供者是具有提供服务功能的特定⾓⾊的服务的实例。服务提供商根据定义的服务接⼝提供服务。
服务使⽤者：服务使⽤者是具有使⽤服务功能的特定⾓⾊的服务实例。服务使⽤者需要确保从提供者获得定义的服务接⼝。
服务端⼝：服务端⼝是服务提供者或使⽤者之间互相通信的接⼝点。
服务接⼝：服务接⼝是服务提供者和使⽤者之间数据交换的定义。它定义了向使⽤者公开的服务的属性。服务接⼝具有以下内容：
•使⽤getter和setter将字段转换为属性；
•⽅法（请求和响应）；
•fire-and-forget ⽅法（请求⽆需响应）；
•事件和事件组；
⽅法-请求和响应：这是服务接⼝的⼀部分，在客户端或者服务器中调⽤⽅法并期待得到确认。
fire-and-forget⽅法：这是服务接⼝的⼀部分，在服务接⼝中，客户机在不等待服务器确认的情况下调⽤该⽅法。
事件：这是服务接⼝的⼀部分，服务⾓⾊在其中更新数据或传递操作。服务使⽤者可以订阅事件或者事件组。
属性或字段：这是表⽰服务器中某些数据的服务接⼝的⼀部分。服务器应该通过公开getter和setter⽅法向使⽤者提供该数据的访问。
参数：它定义⼀个⽅法的输⼊或返回参数（请求/响应和fire-and-forget⽅法）。
⾯向服务的体系结构：每个特性或系统的SOA包括具有id的服务定义、服务⾓⾊（提供者和使⽤者）、服务器接⼝定义以及与定义的服务接⼝相关的相互接⼝的服务⾓⾊。
组合：⽤于按层次结构组织软件组件。
应⽤软件组件（SWC）：它表⽰在软件体系结构层具有⾜够粒度的给定功能。它应该⾜够细化，可以部署在单个硬件组件上。SWC应为AUTOSAR经典或⾃适应或⾮AUTOSAR软件组件。如果是AUTOSAR经典或⾃适应，则必须按照标准AUTOSAR定义遵循类型-原型-实例结构。
软件端⼝：软件端⼝存在于软件组件上，表⽰操作（如果是客户端服务通信）或数据元素（如果是发送⽅=接收⽅通信），提供或订阅的数据，发送⽅-接收⽅接⼝或客户端接⼝被分配给软件端⼝。
软件组装连接器：通过使⽤软件组装连接器（软件级数据流）连接软件端⼝，使软件相互连接。
客户机服务接⼝、操作和参数：如果软件端⼝以客户机和服务器模式交换数据，则分配给它们的接⼝称为客户机服务接⼝。这个接⼝需要包括每个操作的操作和参数（输⼊和返回）。
发送⽅=接收⽅接⼝和数据元素：如果软件端⼝以双向模式交换数据，则分配的接⼝称为发送⽅-接收⽅接⼝。此接⼝需要包括数据元素（表⽰交换的数据）和数据类型分配。数据类型应为应⽤数据类型和实现数据类型。应根据这些数据类型定义计算⽅法。
SOA设计—图表设计
SOA设计和软件架构( architecture)数据应以表格格式或图表形式可视化。
应使⽤定制的表格格式来可视化SOA设计数据和软件架构定义⾯向服务的体系结构图(SOAD)：该图应可视化给定功能或服务、服务⾓⾊(服务提供者和服务使⽤者)、服务端⼝和服务接⼝。下⾯是SOA图的⽰例视图:
软件架构图（SWAD）：⼀旦SOA定义完成，就应该定义软件组件⽅⾯的服务部署。此图显⽰了⽤于数据交换的软件组件、软件端⼝及其之间的连接（软件程序集连接器）。还应显⽰每个软件组件上部署的逻辑功能。下⾯是软件架构图⽰：
车载SOA软件架构：服务设计
•服务定义
服务使⽤SOME/IP总线向客户端提供⼀些功能。所提供的功能既可以作为请求消息公开，也可以作为发送消息公开。•服务集划分
服务是基于⼦系统重新划分集的。
•服务描述模板
服务描述必须包括以下信息：
服务描述：服务⽬的的简单描述。
消息类型：⽅法或事件。
讯息名称：讯息名称。
消息描述：消息⽤途的简短描述。
消息输⼊参数：此规范类型使⽤的输⼊参数的完整列表。
返回参数：此规范类型使⽤的返回参数的完整列表。
此外，必须描述枚举和⾃定义类型。
AUTOSAR-AP平台SOA相关技术规范概述
AUTOSAR-AP平台采⽤SOA⽅法论，主要涉及⼀种⾃适应软件产品的开发，是⼀套包括软件分析、设计、开发、部署在内的复杂⼯作流程。主要包括两个⽅⾯：⼯作流定义与成果物定义（如图2-2)。具体描述如下：
流程定义
流程定义
AP平台的⽅法论作为CP平台的扩展，其引⼊了新的概念，AP平台软件的实例是在进程的上下⽂中执⾏。AP平台引⼊了“机器”(Machine)的概念，“机器”是虚拟化的ECU,⼀个可以部署软件的实体。它可以是真实存在的处理器，也可以是⼀个虚拟机，AP软件则运⾏在某⼀特定的“机器”上。
(1)开发服务接⼝(Service Interface)
AP平台是⼀个⾯向服务的软件架构(SOA)，基于AP平台的软件开发，⾸先需要进⾏服务接⼝的设计。服务接⼝可以由事件(Events)、⽅法(Methods)和字段(Fields)组成，是⽣成软件组件头⽂件的基础。
(2)开发通信结构(Communication Structure)
OEM在设计阶段需要指定预期“机器”(Machine)的通信结构以及相应的配置参数，包括机器的所有⽹络端点和服务发现地址端⼝等。这⼀步将产⽣⼀个可交付的“机器设计”(Machine Design)，⼀个特定的“机器”模型将引⽤⼀个特定的“机器设计“ 模型。
(3)开发⾃适应应⽤软件(Adaptive Application Software)
⾃适应应⽤软件开发从软件组件(SW component)的设计开始，软件组件是通过其端⼝(Port)定义的，每个端⼝实现⼀个服务接⼝。基于服务接⼝描述，⽣成包含实现软件组件的头⽂件。开发⼈员在此基础上实现软件组件的核⼼功能。
(4)开发⾃适应平台软件(Adaptive Platform Software)
与应⽤级软件类似，平台级软件可以由基于标准化服务接⼝的软件组件组成，也可以直接实现⽽不需要软件组件模型。
(5)定义和配置机器
包括了功能组状态和每个状态超时的定义，进程到特定机器的映射，以及平台服务（例如NM、DoIP)
和基础模块（例如⽇志）配置等。此过程会产⽣⼀个独⽴于服务实例或应⽤程序的机器清单(Machine Manifest)。
(6)集成软件
软件的实现和编译完成后，需要集成到⼀个可执⾏⽂件CExecutable)中。通过进程来定义特定机器上可执⾏⽂件的实例化，每⼀个进程会产⽣⼀个执⾏清单CExecution Manifest)，其中包括了进程及其启动配置。
(7)定义和配置服务实例(Service Instance)
⾸先对服务接⼝进⾏部署，然后定义服务接⼝的实例，并决定是否提供或使⽤该服务实例。其次要建⽴服务实例到机器的映射，以及服务实例到端⼝的映射。此过程会产⽣进程所需的所有服务实例清单(Service Instance Manifest)。
(8)⽣成软件包(Software Package)
将可执⾏⽂件及所需清单整合为软件包上传到机器上，⽽⽆需重新刷写。OEM可以将软件包存储在后端服务器中进⾏统⼀管理。
⼀管理。
成果物定义
由于AUTOSAR的⼯作流包含了整个汽车软件开发流程，涉及多个开发⾓⾊，因此需要各个开发⾓⾊之间有信息交互，为了保证信息不出现⼆义性，需要对各个环节的⼯作成果物规则进⾏定义。同时为了信息的保存、传输、交互的需求，需要定义这些成果物的载体，ARXML就是定义了不同流程成果物的载体，使⽤不同的标签来表⽰不同的信息及流程，这些标签的定义就是AUTOSAR的数据元模型（如下图)。
MO: 使⽤Ml级规则⽣成的可运⾏软件实体，例如车门控制的可⾃⾏软件组件
Ml: 使⽤M2级规则定义软件组件，例如车门控制的软件组件，软件组件的表现形式可以是ARXML,C/C+＋语⾔或各类⽂档。⼀般情况下会使⽤⼯具链以ARXML的形式定义软件组件的框架，然后导⼊下游⼯具链⽣成⽬标语⾔。或直接⽣成⽬标语⾔框架，然后⼿写代码的形式完成整体的软件组件；
soa
M2: 使⽤M3级规则定义使⽤AUTOSAR开发的元素、语法及规则，例如软件组件，port⼝，机器，清单等。该级别的元素与具体的功能⽆关，类似于各类开发语⾔的语法；
M3: ⽤于定义M2的元模型。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。