SOA 軟件架構設計方面

聯(lián)合汽車電子：

在某客戶項目中，整車廠規(guī)劃基于新一代中央域控+區(qū)域接入的電子電氣架構實現整車功能服務化，聯(lián)合電子應用業(yè)務驅動型開發(fā)方法幫助整車廠完成整車服務架構設計。

圖 6-3 SOA 服務架構設計過程展開

業(yè)務驅動型指從業(yè)務用例出發(fā)，以服務為導向，正向設計 SOA 汽車軟件的開發(fā)方法。在設計過程中，通過“業(yè)務過程分析”、“服務操作分析”、“候選服務分析”三個步

驟，解決“應該構建哪些服務？”、“每個服務應該封裝什么邏輯？”兩個核心問題。

以雨刮子系統(tǒng)為例，客戶提出雨刮低速、雨刮高速、雨刮點動等多個場景用例，分析過程如下：

業(yè)務過程分析：

采用用例驅動的方法來分析業(yè)務需求和過程。用例驅動指從用戶使用的角度而非開發(fā)人員的角度考量功能需求和系統(tǒng)實現，重視從系統(tǒng)外部觀察對系統(tǒng)的使用。由用例驅動的開發(fā)活動，可以建立需求和服務操作之間清晰的追溯關系，為抽象和封裝服務提供充足的語境信息。

雨刮低速

雨刮高速

雨刮點動

服務操作分析：

服務封裝的業(yè)務邏輯，由服務操作實現。服務操作代表了服務所執(zhí)行的特定動作，可類比軟件中的方法或函數。

服務操作分析過程

候選服務分析：

“SOA 汽車軟件分層模型”為候選服務分析提供了有價值的參考。根據重用性和自主性的面向服務設計原則，參考三層模型設計元服務和基礎服務。對元服務和基礎服務的設計，SOA 鼓勵即使沒有立即重用的要求，也要根據服務導向的設計原則促進重用，因此潛在的重用也要考慮在內。通過良好的 SOA 設計，當業(yè)務用例增加，或原有業(yè)務用例發(fā)生變更時，良好的基礎服務和元服務設計，保證了重用性和較少的軟件變更，從而實現更快速高效的功能迭代和清晰明確的版本管理。

候選服務分析結果

服務接口設計：

服務接口設計是服務架構設計過程中的重要一環(huán)，在候選服務分析完成后，大致暴露的服務接口會被確定，服務接口決定了服務之間的動態(tài)數據交互，決定了業(yè)務邏輯的行為和功能，需要在迭代中不斷完善，反復更新。

此處，值得一提的是原子服務和設備抽象服務接口的設計和定義), 設備抽象服務解決電子電氣架構中不同執(zhí)行器/傳感器暴露統(tǒng)一的接口問題，原子服務則對傳感/執(zhí)行器的語義做統(tǒng)一的規(guī)劃和定義。聯(lián)合電子將對原子服務和設備抽象服務接口的設計定義為平臺驅動型(由下至上)設計方法下的工作產出。

當前，軟件定義汽車工作組發(fā)布的API 參考文檔為定義智能汽車軟硬件接口標準化的規(guī)范性文件。工作組通過對 API 接口的標準化定義，為各領域帶來全新的體驗，聯(lián)合電子也正在參與 API 接口定義工作，并在項目上進行應用實踐。

服務部署：

在 SOA 軟件開發(fā)過程中，服務的部署涉及到整車電子電氣架構的信號矩陣。對于業(yè)務驅動型分析方法，功能需求導向是設計原則，對于Tier1 熟知的業(yè)務邏輯領域，推薦Tier1 提供具體服務模塊的部署信息， 這些部署信息作為正向設計的產物，會體現在后續(xù)的整車廠整車軟件架構之中，是整車廠設計整車信號通訊矩陣不可或缺的重要一環(huán)。

在 SOA 軟件架構下，整車廠整體把握軟件架構的總集成方，Tier1 作為各個業(yè)務領域(車控、底盤、動力、高級輔助駕駛系統(tǒng)等)的合作伙伴，將作為組件負責人向整車廠提供對應的架構描述文檔，最終系統(tǒng)級的架構設計文檔由整車廠輸出，并結合軟件模塊和基礎軟件部分，完成各個子系統(tǒng)的集成。

圖 6-4 SOA 架構在軟件中的實現過程

聯(lián)合電子認為， 面向服務化的軟件架構，未來將促進多個供應商體系下軟件集成互相協(xié)同。在這樣的方案里， Tier1 會充當 Component Designer 的角色，是Component 的“專家”，對組件內部的架構設計和業(yè)務邏輯有著主導權；組件與組件之間的接口則由整車廠來承擔和定義，Tier1/軟件供應商在嚴格遵照該定義后，將軟件架構和軟件模塊以固定的形式持續(xù)向整車廠推送。未來逐步迭代和成熟的接口也將是軟件定義汽車的標準接口，其一定程度的抽象可以形成行業(yè)內的標準規(guī)范。