在 IBM Rational Systems Developer 中進行 AUTOSAR 系統建模

AUTOSAR 系統建模

AUTOSAR 已經指定了其自己的 DSL，允許汽車工程師以熟悉的方式對車輛的電力和電子系統進行建模。該語言有四個主要部分，它們稱為模板。它們是：

• 併入虛擬功能匯流排（Virtual Functional Bus，VFB）概念和行為的軟體元件（Software Component，SW-C）
• 硬體描述的電子控制單元（Electronic control unit，ECU）
• 用於 ECU 拓撲，和將邏輯元件對映為物理元件的系統
  • 取決於 SW-C 和 ECU 模板
• 用於描述基本軟體配置的 ECU 配置

此外，已經指定了一個描述使用磨邊描述、構建，和配置 ECU 的過程的方法。

本部分探究了用於 AUTOSAR 系統建模的統一建模語言（Unified Modeling Language，UML）的可用性，以及將要面臨的可能挑戰。

AUTOSAR 系統的基於 UML 的建模

Rational Systems Developer 中的 AUTOSAR 建模支援探究了從 AUTOSAR 元模型 2.1 到 UML 2.1 的可能對映。對於一些模板，在這兩個領域之間存在很好的重疊。利用 UML 和概要檔案的 AUTOSAR 系統開發已經在 Rational Systems Developer 中實現了。它有許多優點，因為您可以容易地使用 IBM® Rational® Software Modeler 提供的圖和分析支援。

圖 1 顯示了利用帶有 AUTOSAR 概要檔案的 UML 結構圖的 VFB 檢視。

圖 1. 利用 UML 的 AUTOSAR 系統建模

Rational Systems Developer 的 AUTOSAR 建模支援允許您建立用於建立模型元素的定製的選單（如圖 2 中所示的那些），這意味著您可以直接建立 AUTOSAR 原型化的 UML 元素。您可以使用 UML 類或結構圖來對 AUTOSAR 軟體元件建模，並且對 ECU 建模（在某種程度上）。您可以很好地利用 UML 結構圖獲得軟體元件的 VFB 結構。

圖 2. 建立 AUTOSAR 原型化的 UML 物件

UML 的侷限性

雖然您可以利用 UML 來捕獲 AUTOSAR 建模的一些方面（像軟體元件模板），但是其他 AUTOSAR 模板（像 ECU 或 System 模板）不能完全地用 UML 建模，如圖 3 所示。這生成了 AUTOSAR 領域專用建模的需求。下一個部分將討論為 AUTOSAR 領域專用問題的建模而設計的 DSL 工具。

圖 3. UML 2.1 與 AUTOSAR 2.1 模板如何重疊
 

AUTOSAR 領域專用語言工具

如前面部分中討論的，只有 UML 不足以捕獲 AUTOSAR 建模的每個方面。這引發了在建模工具中增加領域專用建模（domain-specific modeling，DSM）支援的需求。DSL 是要執行 DSM 的領域的底層模型，並且一般以元模型形式獲取。AUTOSAR 元模型可以利用 Eclipse 建模框架（Eclipse Modeling Framework，EMF）實現。根據 Rational Systems Developer 設計的 DSL 利用 ecore 模型提供領域專用的建模支援，直接從主 AUTOSAR 元模型生成。

EMF 持久層

作為 AUTOSAR 標準的一部分，模型檔案格式是基於一組聯絡到元模型的持久規則而定義的。EMF 原本不支援這種 AUTOSAR 專用的格式或 schema，因此，需要定製的 EMF ResourceManager。致力於 eclipse 的許多組織正在構建相同的持久功能，因此有人正在試圖將這個部分標準化。這種工作的一個例項是開放工具框架（Open Tool Framework，OTF）。圖 4 顯示了用於建立 AUTOSAR DSL 模型的 Rational Systems Developer 的專案瀏覽器的整合。

圖 4. AUTOSAR DSL 工具

對於建立 AUTOSAR 領域元素的選單支援（如圖 5 所示）讓您有領域專用的建模體驗，這幫助您避免 UML 原型的混亂和其中涉及的複雜性。您可以在此進行任何 AUTOSAR 模板的詳細設計，要不然，只利用基於 UML 的建模支援是不可能的。

圖 5. 建立 AUTOSAR 領域模型

定製化的檢視

您可以利用 Rational Systems Developer 中對 AUTOSAR 的領域專用建模的支援來建立詳細且複雜的模型。有時候，通過大型模型導航並找到一個物件和另一個之間的關係是一個難題。

對於 AUTOSAR 的一個這樣的問題是包含其他軟體元件的軟體元件。在 AUTOSAR 中定義包含許多軟體元件的複合的軟體是可能的。複合的軟體物件可以用作元件軟體物件，這些可以進一步組合形成其他複合的型別。僅僅通過模型導航很難追蹤這類層次關係。因此，圖 6 中顯示的 Hierarchical View 用於獲取軟體元件的層次結構。它允許您通過軟體元件的層次導航，因而讓您更好地觀察軟體到 ECU 對映。

圖 6. Hierarchical 檢視

它還用於檢視按照型別分組的模型物件。如果您知道物件的分類或型別，它可以幫助確定並定位模型物件。Category View（如圖 7 所示）實現此目的。這些定製的檢視已經擴充套件為支援 AUTOSAR UML 模型。您可以根據原型來對元素分類，並且還可以顯示軟體元件的包含結構。

圖 7. Category 檢視

AUTOSAR DSL 物件視覺化

不像 UML 標準那樣，AUTOSAR 不提供對建模的任何圖支援。Rational Systems Developer 中對 AUTOSAR 系統的領域專用建模的支援克服了這個缺陷，利用 IBM Rational 的 MMI 框架的視覺化概念，使用一些其他領域的標記元素幫助視覺化一個領域的元素。AUTOSAR 的源領域需要對映到 UML 的目標領域，這依賴於您需要如何視覺化領域專用的物件。

部分利用 UML 類圖來將一些 AUTOSAR 元素（軟體元件、客戶端/伺服器和傳送者/接收者介面，等等）視覺化為類。圖 8 顯示被視覺化為類圖中的類的元素。對於一些 AUTOSAR 元素，儘管它們可以被視覺化為類，但是方法部分或屬性部分（或兩者）都沒有傳達任何內容。UML 標記元素可以定製為使之適應領域專用的需求。

圖 8. AUTOSAR 類圖

VFB for AUTOSAR Software Component（ASC）—— 在抽象層次上定義 ASC 之間通過埠的互動 —— 可以用 UML 2.1 結構圖用圖解法獲取。圖 9 顯示了對於一個 ASC（RainSensing）的結構圖。軟體元件之間通過埠的互動已經被獲取為彙集和委託聯結器。

圖 9. AUTOSAR 結構圖

ASC 的行為建模需要安排 RunnableEntities（它是可以直接轉換為程式碼的系統的元件）。RunnableEntities 的執行安排不可能用現有的 UML 圖適當地獲得。利用圖形建模框架（Graphical Modeling Framework，GMF）的領域專用的圖用於提供對 ASC 行為建模的基於圖的支援。該圖（如圖 10 所示）幫助指定 RunnableEntity 讀取或寫入的資料元素。Properties 檢視支援幫助安排 RunnableEntity 的執行事件。

圖 10. AUTOSAR 內部行為圖

DSL 模型到 UML 模型的雙向轉換

如之前討論的，您可以利用 UML 對一些 AUTOSAR 模板建模，但在 DSL 工具中需要更多詳細的設計。有了 Rational Systems Developer 中的 UML 建模支援，您（作為系統工程師）可以開始利用 UML 進行高層設計。然而，當提到詳細的設計時，您需要將模型轉換為 DSL 模型。

Rational Systems Developer 上的 DSL 工具提供模型到模型的轉換支援，能夠讓您將 UML 模型（帶有 Profile）轉換為 DSL 模型。該轉換支援一組來自 AUTOSAR 的元素的子集。同樣也支援從 DSL 到 UML 的逆轉換（帶有引信功能），以便在任何階段您都可以將 DSL 模型轉換為 UML 模型。圖 11 顯示了轉換配置，其中 UML 模型設定為源，AUTOSAR 模型設定為目標。該方法應該帶來以下優點：

• 提供在選擇的領域中建模的靈活性
• 利用兩種領域的好處

圖 11. UML to AUTOSAR Transformation 的 TC
 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780914/viewspace-588978/，如需轉載，請註明出處，否則將追究法律責任。