來源 |   汽車ECU開發
資料 |  后臺回復【SOA】獲取PDF原文

知圈  |  進“電子電氣群”請加微13636581676,備注架構

根據基于模型的系統工程方法和以下面向服務架構的建模語言(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的元模型。