根据基于模型的系统工程方法和以下面向服务架构的建模语言(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的形式定义软件组件的框架，然后导入下游工具链生成目标语言。或直接生成目标语言框架，然后手写代码的形式完成整体的软件组件；

M2: 使用M3级规则定义使用AUTOSAR开发的元素、语法及规则，例如软件组件，port口，机器，清单等。该级别的元素与具体的功能无关，类似于各类开发语言的语法；

M3: 用于定义M2的元模型。