一片藍海——汽車軟體的前景（二）

在整個SOA演進中，軟硬體解耦是必然趨勢。傳統汽車電子電氣架構（E/E架構）呈現是分散式的，已經不再適應新電子電氣架構的需求（軟體定義汽車時代）。-> 傳統電子電氣架構中軟硬體高度耦合，軟體功能的實現是基於甚至是依賴於硬體。在整個車載研發過程中，若需要增加新的功能，需要改變所有與之相關的Software。與此同時，也需要相應改變車內匯流排佈局、功能、系統升級（Software Update）。會致使修改很是繁瑣，後期OEM整合驗證也會相應的更加複雜困難。特別是需要協同實現功能時，如果其中一個ECU出現問題，可能會導致整個功能全部失效。

->在傳統電子電氣架構中，不同供應商開發不同的軟體架構，互相之間無法實現複用，在新的軟體更新框架下（OTA），無法統一對ECU進行Software update；

->在傳統電子電氣架構中，OEM是整車框架的定義者，但車身具體功能是由ECU獨自完成。整個過程軟體開發的工作是由供應商完成（Tier1）。OEM在驗收ECU具體功能後，對每個供應商提供的ECU進行整合驗證。這也是以往OEM，會有一個車身框架，安裝所有的ECU在整個車身環境進行上電執行驗證其具體功能（主要是在整車環境下，因為對於ECU Supplier而言，沒有這樣的整車驗證的環境，只是做單個ECU功能驗證）。也是因為如此，OEM軟體開發能力普遍偏弱，這個也不是透過挖許多人，成立軟體研究中心一蹴而就；

->隨著車輛駕駛者對於出行需求不斷提升，以及技術不斷更新迭代。車輛也慢慢開始向智慧化和網聯化發展。以往單一控制器策略（單個ECU），以分散式電子電氣架構，實現整車功能控制方法明顯已經不能滿足時下車載智慧產品的開發需求。特別是由於自動駕駛功能概念的引入，對於海量資料的處理、傳輸、以及成本考量。因此車身電子電氣架構轉變不可避免——從分散式架構向域控制器架構、中央計算架構轉變，而集中化的E/E電子電氣架構是實現軟體定義汽車的硬體基礎。

藉助於新的E/E架構，實現軟硬體解耦，軟體功能開發逐漸通用化、平臺化。特別是車載AUTOSAR軟體架構出現。以前車載分散式軟體架構是一種面向Signal的通訊框架，ECU之間透過訊號來傳遞資訊，報文作為資訊的載體。這個框架已經使用多年，是成熟的車載解決方案。整個車身框架是基於車載CAN匯流排佈局，匯流排下面下掛每一個域的控制器，透過CAN ID傳送廣播，實現有效通訊。

但是這裡有一個弊端，整個軟體系統是封閉的、靜態的，全部車載功能定義在編譯階段就完成，若OEM要修改或增加具體ECU的功能定義，或者該需求指令需要呼叫另一個ECU上的功能時，必須把所有涉及到的ECU都進行升級，這樣操作就大大延長開發週期、增加開發成本。整個V模型是固定的，這也是德國人在此處玩的很轉的原因，本身民族的特性就是在固定模式下細化精化完善。

但隨著新的電子電氣架構對車載軟體提出的新的要求，特別是OTA引入，在自動駕駛領域，隨著海量資料的餵養，自動駕駛的演算法不斷在最佳化，這就需要很快的頻率更新迭代車載軟體版本。而原有電子電氣架構下的夜店——軟硬體高度巢狀，會導致硬體之間難以形成較強的協同性，汽車軟體的可複用性和OTA 升級能力整體較弱。

隨著汽車電子電氣架構趨於域控制器化、集中化，域控制器或中央計算平臺以分層式或面向服務的架構部署，整車ECU數量大幅減少（感測器和執行器數量變多），車載控制器底層硬體平臺需車規晶片提供更為強大的算力支援，車載控制器軟體也不再是基於某一固定硬體開發，而是要具備可移植、可迭代和可拓展等特性。汽車原有以ECU 為單元的研發組織將發生轉變，形成通用硬體平臺、基礎軟體平臺以及各類應用軟體的新型軟體架構。這樣的架構可以使軟體功能實現快速迭代，而、這也是諸多OEM在佈局軟體研究中心的核心原因所在。抓住車載軟體能力，相當於在這個浪潮中拔得頭籌。

向如下模式轉換

實現軟體定義汽車的關鍵是提供一個穩定的平臺，因此智慧車載軟體架構需向SOA架構轉變。以往的車載軟體架構是面向訊號的架構（Signal-Oriented Architecture），控制器功能是固定的，軟體被提前編寫在控制器中（量產進行燒錄）。隨著智慧汽車的發展，車載ECU數量逐年增多，導致ECU之間點對點的通訊變得十分複雜，且不具備靈活性和擴充套件性，微小的功能改動都會引起整車通訊矩陣以及各ECU軟體的變動。比如現階段應用最廣的是基於車身CAN匯流排的架構，在設計時，就會定義好整車級通訊矩陣，當有需求變更時，需要涉及的內容會有關聯關係，影響比較大（但是話又說回來，以往車企新車型更新速度也比較慢、比較固定）。同樣情況，對比SOA（Service-Oriented Architecture，面向服務的軟體架構）是一種軟體架構（準確說是軟體設計方法和理念），其特點就是：

-> 對外介面標準化；

-> 軟硬體耦合度低；

-> 框架靈活，且易於擴充套件。

查資料獲知，SOA 架構中每一個服務都具有唯一且獨立互不影響的身份標識（Identifier），其定義了清晰的功能範圍，並透過中介軟體實現自身任務的釋出、對其他服務的訂閱以及與其他服務的通訊工作。透過上述獨立互補影響特點可知，SOA架構可解決傳統架構中因個別功能增減/變更而導致整個通訊矩陣與路由矩陣都要變更的問題（該架構的易擴充套件性）。

另外，SOA架構中每個Service Interface的特性是“標準可訪問”，服務個體的設計、部署不再依賴於具體特定的硬體平臺（低耦合性的特點）、作業系統和程式語言，同樣的元件/功能可以透過標準化介面在不同的車型上實現複用，實現元件的“軟硬分離”，達到跨平臺複用的效果。

在時下汽車智慧化時代，車載軟體的更新迭代頻率越發短暫，因此獨立於硬體的軟體升級是持續為客戶提供價值的關鍵（可參考頭部車企特斯拉的OTA更新頻率）。由於SOA 架構具有“松耦合”的特性，服務元件和硬體均可以標準化地接入和訪問，若要新增某一功能只需增加相應的服務元件並使其呼叫不同的硬體功能即可。這樣可以促使每家的開發人員抽出更多精力和資金專注於上層應用的開發，而無需再對底層演算法甚至各個ECU 中的軟體進行重新編譯，這也解決了相同的應用在不同車型及硬體環境下重複開發的痛點，使得汽車軟體架構十分靈活並易擴充套件。（有好處也有壞處，會容易導致技術壁壘形成，造就技術寡頭）。

在這樣的環境下（軟硬體解耦以及汽車軟體架構向SOA 轉型），車載軟體產業鏈被重新建設，越來越多的玩家加入這樣的行列：

1、越來越多的OEM構建自己的軟體能力，在這個過程中，增強了軟體自研能力、系統架構能力以及SOA架構能力。大部分車企透過合資或者獨資成立自己的軟體研究院，已經完成了軟體自研能力補充或升級，構建了平臺型架構體系，以往傳統車企的開發模式逐步向面向軟體定義汽車的開發模型過渡。

整個過程也劃分不同階段，現主流電動車OEM已經在迅速佈局：

建立軟體自研能力：OEM開始自研車載軟體，將自身需求和設計、程式碼編寫、軟體架構等能力打通；

伴隨自研能力加強，OEM會逐步建立系統建構能力，實現“硬體通用平臺化”與持續可升級；

最終模式是OEM建立自身SOA架構，透過標準的服務介面、耦合度低的服務機制，結合高算力高效能計算平臺，打造汽車“軟體驅動”基礎能力。

2、憑藉這個東風，許多國內外軟體供應商一躍成為Tier1供應商，在整個產業體系中話語權也在不斷加重。隨著新的車載軟體架構不斷更新迭代，其開發難度不斷增加，於此同時傳統的汽車Supplier研發能力難以滿足需求。在這樣的背景下，OEM主動繞過傳統一級供應商，直接與原有的二級供應商（晶片、軟體演算法等廠商）合作。在軟體定義汽車時代，軟體重要性不言而喻，整車廠為了掌握主導權並降低高昂的開發成本，會選擇直接與較強的獨立演算法研發能力的軟體供應商合作。

注：OEM將底層基礎軟體（系統軟體層）作為發展核心，車載SOA架構對汽車生態開啟新的構建，個人猜想汽車行業極有可能複製PC和智慧手機的軟體分工模式。OEM自建或與供應商合作搭建作業系統和SOA平臺，引入大量的演算法供應商、生態合作伙伴等形成開發者生態圈，未來車企能夠向用戶提供全生命週期的軟體服務

。

汽車軟體產業在汽車智慧化的程序中被重塑，從大的方面對於軟體供應商有了更好的機會，一躍成為話語權高的Tier1。我國汽車行業也可以站在一個起跑線上（其實我們已經部分領先），可以有更好的一個行業環境。從小的方面，對於我等從事汽車行業的工程師，也是一個非常不錯的發展機會。政策導向和海量資金湧入，以往不敢設想的技術點，有了更多的突破機會。

因自己一直從事車載診斷行業，新的電子電氣架構也給自己帶來了很多的思考。以往分散式電子電氣架構中診斷需求規範是每一個ECU都有自屬的需求規範，單獨基於這個晶片開打診斷Software即可。做整合測試時，也方便掌控。但是伴隨域控制器、車載乙太網以及新穎的通訊策略，對於診斷功能的定義、診斷功能界定策略都帶來了新的Topic：

1、以往控制器架構更多是單個ECU控制一個功能（BCM、ICM等），現在更多是以域控制器+Sensor和執行器，每個部件診斷判定策略、儲存策略、訊號觸發方式發生改變；

2、更多的車規級作業系統引入，對於Sensor和執行器判定後，怎麼與中央處理器資料互動？出現故障時，以怎樣的觸發方式告知儲存方？

3、當一個故障由多個引發點（Error event），每一個點都來自不同的輸入源，怎麼快速界定？透過定義Snapshot快照資訊是否可以完成此功能？是否也可以UDS原有的框架基礎上，新定義一個自屬服務，完成自己需要的功能？

以上種種，都是茶餘飯後自己對行業的思索，僅供參考！