引言

在軟件定義汽車的浪潮中，中國的主機廠面對的第一道考題，就是如何建設自主獨立的軟件平臺。進而達到軟硬件分離，軟件定義汽車的目的。作為傳統(tǒng)的汽車人如何張開環(huán)抱擁抱互聯(lián)網(wǎng)的沖擊，學習精華盡快完成轉(zhuǎn)型是不容易的。

作為一個傳統(tǒng)汽車人，疊加消費電子產(chǎn)品經(jīng)理，不只是工作，也是愛好和一份思考，將所思所想所學所知整理成文章。才疏學淺，請各路大咖指正，參與討論。

一，SOA架構(gòu)相關

設計與開發(fā)SOA的流程，從描述到代碼。

從頭說起吧，整個從系統(tǒng)到代碼的大致流程應該是這樣的：

1,首先需要整理出整車功能配置列表，這個步驟需要輸出整車級別的邏輯架構(gòu)與功能需求文檔；

2,接下來子系統(tǒng)和功能的網(wǎng)絡架構(gòu)，輸出功能的拓撲圖和具體布置到那個硬件中，類似電子電器架構(gòu)的輸出物；

3,做系統(tǒng)架構(gòu)，在子系統(tǒng)內(nèi)部定義出服務和公共的接口的設置；

4,系統(tǒng)中的服務架構(gòu)和服務的網(wǎng)絡關系，輸出配置方案；

以上四步都是用系統(tǒng)的視角在推進工作，從第四步開始進入了軟件的內(nèi)容定義，算是進入了軟件領域。

5,HPC內(nèi)的架構(gòu)，輸出是將內(nèi)容模塊化，以及寫碼的規(guī)則方法；

6,最后就是做具體的軟件架構(gòu)生成二進制代碼。

后面我會用具體案例和比較說明如何定義一個服務，這里想先預先說明

1，對于定義服務或服務體系結(jié)構(gòu)，沒有通用的標準方法。SOA是一種邏輯推導，而不是一種技術。

2，服務定義基于特定的功能和特性體系結(jié)構(gòu)，和需求相關和硬件相關，因此通常在產(chǎn)品的設計和生命周期中不斷變化。

3，為了優(yōu)化服務架構(gòu)，通常會進行多次迭代，例如將SW功能切換到服務(在集群或應用程序級別)。

4，服務架構(gòu)設計可以與軟件架構(gòu)工作相比較:抽象級別和技術不同，對工程師的要求也是相似的。

二，關于Service的顆粒度是邏輯推導，沒有簡單定義

比較晦澀難懂，舉個例子吧。

所謂服務是一個個獨立的，可以反復利用的，并且易于鏈接的函數(shù)，可大可小?；谶@個定義那么，獨立性，低耦合性，接口通用性就成為服務的三個特性。

如果我們把信號流看做最小的服務，那么硬件能實現(xiàn)的最小功能就是最基礎的服務，如何來定義的顆粒度呢？比如我們把“遠程召喚”作為一個要實現(xiàn)的場景，其中的服務設定為“發(fā)動”+“行駛到指定位置”+“自動泊車”，為什么要把這三項分開，而不是把“遠程召喚”定義為一個服務？原因很明顯“發(fā)動”和“自動泊車”是高頻使用的功能，他們非常的獨立，又有可以重復使用的部分。

那么如果我們增加了“循跡泊車”的功能，服務設定為“行駛到指定位置”+“自動泊車”，那么也許再結(jié)合“完成鎖定通知”就可以重新我們就會把“跑步”獨立成一個服務。最終“健身運動”=“跑步”+“機跑步”+“俯臥撐”+“洗澡”；“夜跑”=“操場”+“跑步”+“洗澡”。

用這個比喻就是想說明，所謂服務的定義，沒有統(tǒng)一的原則方法，是一種邏輯推導，需要有很強的邏輯能力，需要對工程有深刻的理解，需要對整車功能的關聯(lián)性有深刻的理解。所以經(jīng)驗對于SOA的設計是至關重要的。如果展開說去，服務的排列順序，服務的選擇組合都和對車的理解有關，尤其再加深一步到時序相關，牽涉到強實時性的信號流與服務流的結(jié)合，就需要對車的功能有更深一步的了解了。這可能也是很多純粹的互聯(lián)網(wǎng)企業(yè)，擁有強大的軟件實力，確難以很好的完成整車軟件平臺的原因之一。

三，用一個具體的feature來說說SOA

首先，我們假設有如下這樣一個功能需求的描述作為輸入.

Feature Description: Park Buckler

Part_1:定位停車車輛的GPS位置，利用當?shù)氐奶鞖庑畔?暫定為雨)控制所有的窗戶(包括天窗)，在窗戶沒有完全關閉的情況下自動關閉。同時，在關閉所有窗口之前，用戶應該能夠通過安裝的前攝像頭檢查天氣狀況，以驗證是否下雨。

Part_2:車輛停放并上鎖后，如發(fā)現(xiàn)車輛未經(jīng)授權(quán)進入，系統(tǒng)應通過智能手機APP以錄制或直播視頻數(shù)據(jù)或消息的形式通知用戶。

可以看到這里對功能需求的定義是非常粗略的，遠遠沒有達到完整的詳細的水平，那作為一個平臺級的功能的開發(fā)，是如何將一段描述一步步拆解為可以打包成服務的代碼的呢，我們一步步來看。

首先，進行函數(shù)樹的分析，類似于思維導圖，弱邏輯強發(fā)散，旨在把所有和功能的相關項目進行羅列。如下圖，對用戶設置的檢測，通知用戶，預設條件檢測，周圍環(huán)境檢測，內(nèi)部座艙檢測，確認車鎖，確認車窗，確認車的定位，確認時間，確認下雨...在這些一級條件之下，還有更多的二級條件，三級條件...最終形成下圖

那么在有了發(fā)散的函數(shù)樹型圖之后，接下來基于弱邏輯的圖，對功能需求形成有邏輯的描述。

Design Requirements (REQ-General):

1.先決條件檢查(即:硬件安裝和健康狀態(tài)，電源模式，電池水平)在啟用Park Buckler功能之前.

2.故障的判斷機制----為了避免故障事件數(shù)據(jù)通過車輛狀態(tài)的組合發(fā)送給用戶(例如:門的關閉和鎖，窗的位置，公園，小屋和報警狀態(tài))作為算法設計的一部分。

3.用戶體驗-手動(或默認)啟用/禁用的選項和靈敏度的調(diào)整，給定的功能應該提供給用戶通過車內(nèi)娛樂系統(tǒng)或智能手機應用程序。還包括三個級別的靈敏度設置(低，中，高)。

4.連通性——為了避免網(wǎng)絡連接不良，系統(tǒng)應該能夠在本地錄制視頻數(shù)據(jù)，然后在連接恢復正常時將數(shù)據(jù)傳輸?shù)皆?用戶。

Design requirements (REQ-Automatic Windows Close if Raining):

5.準確性:除了REQ-General外，檢測算法還應包含GPS數(shù)據(jù)(確定位置)、導航和光數(shù)據(jù)(確定室外或室內(nèi))、雨傳感器數(shù)據(jù)(利用紅外光數(shù)據(jù)確定雨)和相機數(shù)據(jù)(利用視頻或圖像數(shù)據(jù)確定雨)。

6.在滿足REQ1, 2, 3, 5設置的條件后，激活Windows。

Design Requirements (REQ-Unauthorized Access):

7. 準確性:除了REQ-General之外，檢測算法還應包括接近數(shù)據(jù)(確定入侵者接近車輛的方向和區(qū)域，以初始化預觸發(fā)階段)、客艙攝像數(shù)據(jù)(確定乘員)或/和客艙體積數(shù)據(jù)(確定乘員)。

8.在滿足REQ1, 2, 3, 7設置的條件后，激活Windows.

再有邏輯性的功能描述之后，有必要的移步是手繪出完整的這個功能的邏輯走向，將之前細化分析出的影響功能的相關像都包含在內(nèi)，并且顯示出輸入純屬出的邏輯關系。也有的開發(fā)者會運用熟悉的工具例如Freevision直接就做了。但我認為這一步還是非常有必要的，任何工具都沒有辦法完整的滿足現(xiàn)在日益曾都哦對功能需求的需要，并且存在配置的不完備之處。在計劃的初期就能對整套功能有完整的解構(gòu)，并且存檔，無論是對新來者的理解幫助，還是對主機廠自身知識體系的建設都有很大的幫助。如下圖。

接著可以用熟悉的工具加速開發(fā)，在AOUTOSAR的架構(gòu)下，對函數(shù)進行打包，形成完整的功能函數(shù)。那么也就完成了對一個Feature的開發(fā)，其實潛移默化中也完成了對這個Feature中Service的定義。

在邏輯結(jié)構(gòu)的基礎上，對一些復用價值低的，不能獨立成型的函數(shù)進行打包整合，形成SOA的架構(gòu)設計如下圖，并對接口做好定義就完成。

例如我們要做環(huán)境感知下雨關窗戶這個操作，那么如下圖調(diào)用感知環(huán)境和關窗戶兩個服務，整個調(diào)用服務的流程解構(gòu)如下圖

以上就是一個簡單功能的正向SOA開發(fā)流程，是對功能的理解，也是對邏輯的推導。里面還有很多細節(jié)值得深挖，在做幾張圖的時候其中的根本邏輯和幾大項目都是一致的有連貫性的。甚至如果是在沒有前面的思想逐步推導，直接拿到任何一張SOA架構(gòu)圖，都會覺得晦澀難懂。更別說如果直接拿到的是代碼了。

對于主機廠來說曾經(jīng)的FDD,FDS是整車需求的發(fā)起點，那么在軟件定義汽車的新時代里，盡快的做出屬于自己的有自主產(chǎn)權(quán)的從描述到架構(gòu)到代碼的推導過程，并在此之上進行軟件迭代和硬件增加，功能增加等等，才能夠有條不紊，底氣十足的砥礪前行。