745
在卷硬件、卷算法卷到一定水平后，智能汽車產業(yè)開始卷中間件等“很不性感”的基礎軟件了。
中間件會影響到通信效率，因而，中間件的性能及可靠性，對自動駕駛功能及體驗有很明顯影響。比如，行車功能與泊車功能之間的切換所需的時間，在中間件比較差的情況下，需要10秒鐘；而在中間件比較好的情況下，切換僅需2秒就可以完成。
除這些基礎功能外，掌握中間件更是被一些車企認為是實現(xiàn)“靈魂自由”必不可少的一環(huán)。因此，幾乎每家“不甘平庸”的車企都在自研中間件。
那么，究竟是哪些因素使得車企將自研中間件跟實現(xiàn)“靈魂自由”強捆綁了呢？為實現(xiàn)這一目標，車企自研的中間件需要達到怎樣的標準？自研中間件會遇到哪些困難？如果自研失敗了又怎么辦？ 專業(yè)的中間件供應商可以為終止自研或一開始就沒打算自研的車企提供什么幫助呢？
一．車企為什么要自研自動駕駛中間件？
“我最近反復思考一個問題：為什么當前很多車企的關注點都在中間件上？因為，中間件是一個開發(fā)平臺，在車企看來，一旦中間件能自己掌握了，他們就可以在供應商的方案跟自研方案之間無縫切換，那自由度就可以完全掌握在自己手里上了。 ”
在去年年底的一場沙龍上，某自動駕駛方案公司的戰(zhàn)略負責人拋出了這么一則觀點。
在供應商的方案跟自研方案之間切換需要中間件沒錯，但是，中間件一定就得自研嗎？難道向供應商買的中間不能實現(xiàn)這一目標？
九章智駕在之前的行業(yè)交流中了解到，主機廠對自研自動駕駛中間件有“執(zhí)念”的理由主要有如下幾點——
1.AUTOSAR AP在設計之初對SOA的考慮并不充分，因而對SOA開發(fā)并不友好。存在的問題主要有：1）工具鏈不完善，使用復雜度高；2）資源消耗大，易占用實時域資源，影響安全；3）缺少靈活的API接口，應用開發(fā)難度大。
2.許多供應商為了追求產品的通用性，將AUTOSAR AP做得大而全，但大而全的結果往往是，AUTOSAR AP中的許多功能模塊是主機廠在開發(fā)的過程中所用不到的；并且，大而全的產品往往是充其量將每個功能都做到了80分，卻沒有幾個真正能做到90分的?！安粌H貴，而且還不好用”。
比如，AUTOSAR AP里會有大量端到端的信息安全模塊，但實際上，信息安全模塊是跟主機廠內部自研的PKI或安全體密切掛鉤的，而供應商由于對每個主機廠內部的PKI或安全體系不夠了解，因此，他們所提供的相應模塊都不能正常使用。
這些多余、不能正常使用的模塊，將會對整個系統(tǒng)的穩(wěn)定性、安全性和性能產生負面影響：
增加系統(tǒng)的資源占用，包括內存、處理器和帶寬等，導致系統(tǒng)性能下降，響應速度變慢，甚至出現(xiàn)系統(tǒng)崩潰或死鎖等問題；
可能存在安全漏洞或后門，這些漏洞可能被攻擊者利用來進行惡意攻擊、信息竊取或破壞系統(tǒng)的行為，從而增加系統(tǒng)的安全風險；
增加系統(tǒng)的復雜度，導致系統(tǒng)的維護和管理變得更加困難，成本也會更高。
因此，主機廠需要對供應商提供的功能模塊進行審查和裁剪，只保留系統(tǒng)所需的核心功能，以確保系統(tǒng)的穩(wěn)定性、安全性和性能，但這個過程費時費力。
3.AUTOSAR AP的開發(fā)標準較多，開發(fā)過程又主要依賴供應商，而供應商的配合度又不可控。
4.使用供應商的中間件，在遇到問題后需要提供證據(jù)證明是“中間件的問題”，很容易扯皮，進而會影響到項目進度。
5.供應商提供的中間件，往往帶有該供應商內部開發(fā)模式、組織架構的“印跡”，若主機廠的開發(fā)模式、組織架構跟該供應商的開發(fā)模式、組織架構不一致，則供應商的中間件用起來比較麻煩，可能會使新車型的量產進度受到影響。
6.很少有中間件供應商能提供一套完整的中間件，而來自不同供應商的中間件又沒有統(tǒng)一的標準，如果在同一個項目中使用來自不同供應商的中間件及工具鏈，彼此之間的適配成本會非常高。
7.供應商開發(fā)的中間件是否達到了其在PR中所宣傳的功能安全&信息安全標準，虛假難辨。在實踐中，主機廠花在驗證上的工作量特別大。
8.擔心中間件供應商破產，危及自身新車型的量產。
9.過去為AUTOSAR CP所支付的高昂成本，已經(jīng)讓主機廠有心理陰影了。主機廠認為，只有必需的組件從供應商處采購，其他的自研則可以減少被供應商盤剝。
10.未來需要將自動駕駛域、座艙域、底盤域進行融合，不同域之間必須進行交互，自動駕駛方案商或自動駕駛中間件廠商開發(fā)的中間件，存在無法識別車內其他域的通信協(xié)議的問題。
二．車企自研的中間件應該滿足哪些標準？
根據(jù)九章之前做的采訪交流，車企自研的中間件，至少要滿足如下標準——
（一）基礎指標
1.傳輸實時性：傳輸時延小于20毫秒。
上層軟件并不直接訪問硬件，而是需通過中間件實現(xiàn)，因此，若中間件無法滿足實時性要求，則無法保證應用層實現(xiàn)其所要達到的功能。比如，通過中間件訪問毫米波雷達數(shù)據(jù)慢兩拍，就會導致模型運算結果出現(xiàn)較大誤差，對駕駛安全性存在較大影響。
2.傳輸正確性：中間件在傳輸、解包的過程中需維持信號一致，實現(xiàn)精準發(fā)送；若無保護機制，則容錯允許偏差值應該小于1%。
3.穩(wěn)定性：不存在數(shù)據(jù)發(fā)送頻率不一致、抖動、丟幀的情況。
4.功能安全：不同的OEM對于安全重視程度不同，導致對功能安全、網(wǎng)絡安全要求存在差異化。總體來說，傳統(tǒng)車企對功能安全的重視程度高，而新勢力對功能安全的重視程度低（對功能安全不做強制要求）；但隨著智駕等級越來越高，功能安全需要滿足ASIL-D標準，至少是那些影響到運行過程和數(shù)據(jù)有效性、安全性的關鍵中間件模塊需達到ASIL-D。
5.信息安全：需將加密算法庫移植進信息安全模塊，同時要保證硬件能夠實現(xiàn)信息安全的加解密處理。
6.有冗余機制：若中間件停止工作，會有備份發(fā)包機制將已處理好的數(shù)據(jù)再發(fā)出去，并且上報。
7.自動故障檢測功能:能檢測到自身存在的故障，并上報。
8.CPU占用：對CPU或BPU占用不能過多。
（二）高階標準
1.工具鏈適配性：工具鏈適配性雖不是硬性指標，但非常影響開發(fā)效率。
2.能對數(shù)據(jù)刷寫過程做診斷：以往，MCU上的數(shù)據(jù)量較小，僅通過CAN總線的刷寫即可滿足需求，而當前，SoC芯片上的數(shù)據(jù)量很大，僅通過CAN總線做刷寫已無法滿足需求，因此，需要中間件承擔一部分刷寫的任務，并且，中間件還需要能對刷寫的過程做診斷。
3.具備分布式通信框架：高階自動駕駛功能部署的節(jié)點、通信數(shù)量較多，要求中間件的調度管理模塊具備分布式通信框架。
4.與硬件平臺的兼容性：中間件模塊需包含hardware硬件抽象層，兼容不同硬件的物理特性、功能特點，形成抽象隔離，可跨SoC平臺使用。
5.對底層軟件具備較高兼容性：需兼容多款操作系統(tǒng)，包括微內核、宏內核系統(tǒng)等。
6.對特定設備開放接口：比如，超級T-Box接收的V2X數(shù)據(jù)在傳輸?shù)倪^程中需要通過無線通信的方式進行數(shù)據(jù)交互。這就需要中間件對T-Box開放接口。
7.具備不同應用和服務信息的訂閱與發(fā)布功能：目前，中間件尚不能在不同的硬件平臺上“游刃有余”，但調用大量的API實現(xiàn)異構通信又是有必要的，因此，在不同的環(huán)境中，中間件需要不同的訂閱與發(fā)布機制。
8.與SOA架構的適配性：中間件應能適配主機廠的SOA框架，功能應具有可擴展性、未來可OTA，還可以根據(jù)用戶需求做裁剪。
9.支持跨域協(xié)同：即把傳統(tǒng)IT行業(yè)里用于云計算的那一套技術棧和解決方案都搬到車里面，用一套通用的計算框架在底盤域、自動駕駛域、座艙域之間做一些跨域的數(shù)據(jù)采集與調動，以及通用計算，以方便跨域協(xié)同。
中國車企推出新車型的速度很快，且車型的迭代速度也很快，而每個車型的車內通信矩陣和元器件、執(zhí)行應用能力都不一樣，由于缺乏一套通用的規(guī)范和工具，這就導致，每開發(fā)一個車型，大量的工作就需要充分做一遍。
這個過程中，不僅工程量超大，而且，工程復雜度也難以控制。在涉及艙駕融合（不局限于one-chip方案，還包括one-box方案）等跨域融合的情況下，尤其如此。
為減少工程量，并將工程復雜度控制在合理水平，目前，大家都在探索一種跨域中間件，或者稱之為全域中間件/整車中間件——主要負責對整車的硬件抽象層進行調度，把整車的各個零部件通過API的形式提供給算法。
三．車企自研中間件的難點
當然，車企要自研中間件，并不容易。
比如，在技術層面，難以同時兼顧性能與功能安全——若需一味保障功能安全，則性能提升將面臨很大瓶頸，且存在較大未知性。鑒于此，有一些主機廠的做法是為了保全性能而犧牲功能安全。
當然了，比技術難題更突出的，是人才和組織方面的難題。
1.人才匱乏
中間件這種基礎軟件，如果要做成生命周期比較長的產品，需要行業(yè)里最頂尖的團隊。但行業(yè)里最牛逼的人就那么多，僧多粥少，想要自研中間件的公司越多，平均下來每一家能招聘到的人才就越少。
事實上，基本上每家要主機廠的自研團隊都面臨人才不足的問題。
筆者想起，幾年前，缺芯問題嚴重的時候，網(wǎng)上流傳過一篇很有意思的文章《為什么芯片公司越多，大家越造不出芯片》，這篇文章的主要觀點是：造芯片需要一個成建制完整的團隊，結果呢，芯片公司越來越多，而人才在短期內并不會有大幅度增長，那新成立的公司就只能從存量的公司里面挖人，挖來挖去，每家公司都缺乏一個成建制的完整的團隊。
上述邏輯，同樣適用于中間件的自研。
2.管理困難
部分傳統(tǒng)車企的管理層缺乏軟件思維，難以協(xié)調管理好眾多的軟件人才。
尤其是，主機廠的部門墻普遍比較嚴重，那么，在做跨域中間件時，你如何保證底盤團隊、智駕團隊跟座艙團隊能精誠協(xié)作？
即便是費了九牛二虎之力研發(fā)出來了，車企也很難輕而易舉地享受“勝利成果”。
1.上下層軟硬件供應商的配合度低
車企自研的中間件若出現(xiàn)問題，將會涉及到上層應用以及下層硬件平臺的修正，若該中間件已量產上車，上下層軟硬件供應商通常不會配合處理因車企自研引發(fā)的問題。
2.后期維護成本很高
有一個德國主機廠，本來在中間件自研上面已經(jīng)走得很深入了，結果發(fā)現(xiàn)很難再走下去了——該車企在前期的確招了很多優(yōu)秀的工程師，但后來發(fā)現(xiàn)，這些最優(yōu)秀的工程師，精力都被綁定在對現(xiàn)有系統(tǒng)的維護上面了。
很多純硬件思維的老板對自研有一個深刻的誤解，好像只要把東西“做出來”就可以“一勞永逸”了，殊不知，軟件系統(tǒng)的維護成本要比硬件高得多。尤其是，一款基礎軟件如果做得比較好，那它的生命周期一定要長，而生命周期越長，維護成本就越高。
很多人會想當然地認為，把自研工作交給一流的軟件人才做，后期的維護工作交給二三流人才，但這顯然行不通。二三流的人才，如果對軟件的理解達不到一流人才的水平，那他如何能做好維護工作呢？
可如果最優(yōu)秀的工程師都被綁定在一個特定的自研系統(tǒng)的維護上，那你還要不要干別的事情了？
現(xiàn)在，這家國際車企終于想通了，決定將中間件及工具鏈交給專業(yè)的供應商。果然，“真正教人學會成長的，不是大道理，而是南墻”。
實際上，去年下半年以來，許多在前幾年一本正經(jīng)地自研的主機廠都開始認清了形勢，逐漸回歸到了行業(yè)協(xié)作的模式上。
四．放棄中間件自研的主機廠，能從供應商得到怎樣的支持？
在行業(yè)協(xié)作模式中，專業(yè)的中間件供應商是一股非常重要的力量。主機廠的短板，得由他們來補上。那么，專業(yè)的中間件供應商能為主機廠解決哪些主機廠自己很難解決的痛點？為解決這些痛點，他們又推出了怎樣的技術與產品呢？
帶著這些疑問，筆者前段時間跟博世旗下軟件定義汽車中間件、開發(fā)工具鏈子公司易特馳中國CTO鄭心航做了深入交流，有不少收獲。為更方便大家了解專業(yè)供應商在這塊的差異化能力，在此，我們將易特馳的做法簡單列舉幾項——
1.對大而全的AUTOSAR AP進行裁剪，只保留主機廠需要的部分
我們在文本的第一章提到，許多供應商為了追求產品的通用性，將AUTOSAR AP做得大而全，但大而全的結果往往是，AUTOSAR AP中的許多功能模塊是主機廠在開發(fā)的過程中所用不到的；并且，大而全的產品往往是充其量將每個功能都做到了80分，卻沒有幾個真正能做到90分的?！安粌H貴，而且還不好用”。
這些多余、不能正常使用的模塊，將會對整個系統(tǒng)的穩(wěn)定性、安全性和性能產生負面影響。因此，針對主機廠的實際需求，易特馳可以將AUTOSAR Adaptive進行模塊化的獨立銷售與部署。
2.解決corner case在仿真平臺上“難以復現(xiàn)”的問題
在corner case出現(xiàn)之后，如何在仿真平臺上對該corner case進行復現(xiàn)呢？這是自動駕駛系統(tǒng)開發(fā)過程中的一大痛點。
對corner case進行復現(xiàn)，需要中間件平臺能支持確定性的輸入輸出。所謂“確定性的輸入輸出”，即傳感器在輸入一組數(shù)據(jù)后，控制算法輸出的控制指令應該也是確定的、可預測的（無論何時何地，只要輸入條件相同，系統(tǒng)的反應和行為就應該保持一致）。但實際上，現(xiàn)在很多中間件平臺（如AUTOSAR AP）并不支持確定性的輸入輸出，這就會給開發(fā)者們帶來很大的困擾。
比如，在自動駕駛系統(tǒng)在真實路測中未能對某個玩滑板車的小孩做出“反應”，而在仿真平臺上，系統(tǒng)對這個小孩卻是“有反應”的。但由于中間件不支持確定性的輸出輸入，那即便是這次在仿真平臺上“順利應對”了那個玩滑板車的小孩，開發(fā)者也不能斷定，問題是否真的已經(jīng)被修復了。
場景復現(xiàn)的問題解決不了，自動駕駛算法的開發(fā)效率就上不去。
那么，為什么許多中間件都無法支持數(shù)據(jù)的確定性輸入與輸出呢？筆者了解到的原因主要有如下幾點——
通信效率問題：自動駕駛系統(tǒng)需要處理的數(shù)據(jù)量很大、進程又多，并且還需要在毫秒級的時間內做出決策，這對中間件的通信效率提出了很高的要求。
標準化問題：自動駕駛領域的標準和協(xié)議仍在發(fā)展中，這可能導致中間件在不同系統(tǒng)和組件之間的兼容性和互操作性問題。
時序保證不足： 各個不同傳感器所收集到的數(shù)據(jù)傳至處理器上的時間是不一致的，而AUTOSAR AP可能無法提供足夠的時序保證，導致系統(tǒng)在不同情況下的響應時間不一致或無法滿足實時要求。
對異構性的支持不足： 自動駕駛系統(tǒng)通常需要集成多個不同類型的傳感器和執(zhí)行器，并與其他子系統(tǒng)進行通信和協(xié)作。如果AUTOSAR AP不支持對這些異構組件的有效管理和協(xié)調，可能就會導致系統(tǒng)的行為不可預測。
針對上述痛點，易特馳跟博世集團的智能駕駛與控制系統(tǒng)事業(yè)部聯(lián)合開發(fā)了一款“能實現(xiàn)數(shù)據(jù)確定性調度和確定性回放”的中間件EDMS，并提供完整的自動駕駛系統(tǒng)從架構設計、算法開發(fā)、數(shù)據(jù)錄制，仿真回放等一整套工具鏈。
EDMS的推出，顯然會幫自動駕駛系統(tǒng)的開發(fā)者們降低在仿真平臺上對corner case做復現(xiàn)的難度，進而提高開發(fā)效率。
3.解決“AUTOSAR AP對SOA開發(fā)不友好”的問題
雖然不少OEM基于AUTOSAR AP 進行開發(fā)，但AUTOSAR AP在設計之初對SOA的考慮并不充分，因而對SOA開發(fā)并不友好，存在的問題主要有：1）缺少靈活的API接口，應用開發(fā)難度大；2）工具鏈不完善，使用復雜度高。
ETAS在與主機廠的項目合作中發(fā)現(xiàn)，API本身的設計并不是難點，真正的難點在于：隨著車型的迭代加速，不同車型的可編程能力也快速變化著的，如何能便捷高效地解決跨車型的API發(fā)布和變更管理？
ETAS提供了基于行業(yè)標準VSS的一系列開源開發(fā)工具鏈，能夠讓主機廠的自主、自動高效的將車內API與中間件的開發(fā)設計，與底層控制器與控制信號自動整合。
4.通過“全域中間件/整車中間件”來提升技術的復用度
當前，自動駕駛方案的通用程度有多高？
對筆者拋出的這個問題，易特馳中國CTO鄭心航的回答是：這就看你怎么定義“通用”了——
如果要求跨主機廠“通用”，顯然不現(xiàn)實；
在同一家車企的不同車型上通用，也很難；
即便在同一個車型上，跨域中間件能否通用，也要看該車型的平臺及EE架構是否發(fā)生了變化——如果融合的架構做得不夠好的話，自動駕駛方案在應用到同一車型的不同款式上時還是需要做大量的手工調試工作。
國內車企跟國際車企有一個很大的差距就是，平臺化的成熟度比較低，因而，技術的復用度很低。
國際車企，往往是一個大的平臺開發(fā)完之后，至少在未來的十年內，好多不同的車型都可共享這一個平臺；但國內車企在這些年由于迭代節(jié)奏比較快，在平臺化建設上花的精力并不是很多——很多時候，都是為了趕項目進度，顧不上做平臺化建設，在遇到問題后再通過“一事一議”的方式來解決，而這種權宜之計，盡管在當時看來是效率很高，但在從長期看，并不利于公司能力的積累。
可以料想，今后，隨著國內車企不斷推出新的車型，因技術復用度低而來的工程復雜度會加劇。
當前，易特馳正在探索通過集成度更高、性能更強大、工具鏈更好的全域中間件（又稱為“整車中間件”）來解決自動駕駛方案的通用性及跨車型共享的問題，從而大幅度提高自動駕駛方案在跟不同車型適配時的效率。
5.從“人的效率”與“機器的效率”兩個角度來提升中間件的效率
有算法公司的人反映，自動駕駛中間件產品存在的最大問題就是效率問題，主要體現(xiàn)在上層應用開發(fā)效率、數(shù)據(jù)回傳效率、傳輸效率、任務搶占等。
易特馳中國CTO鄭心航的解讀是，這里的效率，應該包括“人的效率”（在開發(fā)的過程中，工程師解決一個問題需要耗費多少時間）與“機器的效率”（最終裝車以后，系統(tǒng)在運行過程中需要耗費多少 CPU、 多少內存）兩類。
為提高“人的效率”，易特馳引進了DevOps，通過DevOps將汽車軟件在開發(fā)、編譯、測試、驗證當中的大量工作自動化。比如，一行代碼上傳上去后，DevOps可以自動生成質量報告，告訴上傳者，他的哪一段代碼是有問題的。
其實，DevOps并不是什么新鮮概念，它在十幾年前就在IT行業(yè)內應用了。DevOps的提出主要是為了解決軟件開發(fā)團隊和運維團隊之間的協(xié)作問題，確保在開發(fā)者修改并提交代碼、完成測試驗證之后，這個代碼能快速地部署到客戶的生產系統(tǒng)里面去。
智能汽車做好OTA，就離不開DevOps。
為提高機器效率，易特馳的對策是，在跨域協(xié)作中，將對功能安全和實時性要求高的模塊跟對功能安全和實時性要求低的模塊解耦，這樣，在將來軟件變化的過程當中，盡可能只去改那些對功能安全要求不高的模塊，而對功能安全要求高的模塊則盡可能保持穩(wěn)定。
此外，易特馳還用深嵌入式 AUTOSAR 強實時控制每一個控制器上的進程、資源消耗、循環(huán)的復雜度，以此確保系統(tǒng)能在強功能安全下運行，并且性能不會受到其他系統(tǒng)的影響。
6.加入硬件加速模塊，為“大模型上車”做好準備
后續(xù)，大模型上車會對自動駕駛基礎軟件的能力提出哪些要求？ 博世集團是否有相關的技術儲備？
筆者從博世智能駕駛與控制系統(tǒng)事業(yè)部得到的答案是：中間件有硬件加速模塊，可幫助算法代碼更方便地使用芯片底層提供的各種功能，大模型上車后，中間件也會同算法團隊協(xié)同，保證基于深度學習的模塊在系統(tǒng)中高效運行。
中間件的硬件加速模塊是一種專用硬件設備或組件（包括網(wǎng)絡加速器、加密解密加速器、壓縮加速器、數(shù)據(jù)庫加速器等形式），旨在通過專用硬件設備或組件來加速特定的任務或操作，從而提高中間件系統(tǒng)的性能和效率。
相對于純軟件實現(xiàn)來說，這些硬件加速模塊可以減輕主處理器的負載，因而，通常能夠實現(xiàn)更高的性能和吞吐量，從而滿足對性能要求較高的中間件應用場景。
當然，并非所有的中間件都具有硬加速模塊。只有在中間件需要處理大量的數(shù)據(jù)流或執(zhí)行復雜的計算任務時，硬件加速模塊才是必要的。
7.提升中間件工具鏈的“易用性”
目前，中間件還存在一些問題，主要是工具鏈的易用性不夠，客戶公司工程師的學習曲線比較陡峭、學習周期比較長。比如，AUTOSAR AP本身不具備訂閱和發(fā)布的機制，這就需要嵌入另一種中間件如DDS進去，而域控與域控之間的相互通訊又要考慮加入SOME/IP進去，這會存在各模塊之間的耦合性不夠的問題。
如何縮短工程師的學習周期呢？易特馳的做法：
1）.就是前面說過的，將對功能安全和實時性要求高的模塊跟對功能安全和實時性要求低的模塊解耦，通過這種架構上的分割，給開發(fā)者們提供一個簡單易用的開發(fā)環(huán)境（開發(fā)者們基本上不用去碰、甚至也不需要特別懂那些對功能安全和實時性要求高的模塊了）。
2）.跨業(yè)務部門將工具鏈打通，提升工具鏈的集成度。
整車軟件開發(fā)的生命周期，涵蓋了電子電控架構設計、信號矩陣編排、控制算法建模、代碼生成、仿真測試、整車標定測試驗證等等過程，其中每個細分領域的工作都可能會涉及到十幾個不同部門、幾十個不同供應商的軟硬件工具。針對這一點，ETAS推出了軟件工廠的概念，除了對自身傳統(tǒng)的軟件開發(fā)工具鏈加強了全過程自動化整合，也能對第三方甚至競爭對手的產品進行自動化過程打通。
五．九章與易特馳中國CTO對話實錄
下文為九章智駕與易特馳中國CTO鄭心航的對話實錄——
九章智駕：您去年在接受《中國汽車報》采訪時說：“今后，對于汽車軟件新功能的開發(fā)，我們會盡可能避免變更控制器軟件本身，而是將其作為底層驅動來看待，這將是開發(fā)范式的一個顯著變化?！?這段話該怎么理解？
鄭心航：我舉一個例子：假如你要開發(fā)一個在手機上用的社交軟件，那你需要去改攝像頭的驅動、去改存儲SD卡的驅動、去改通信基帶嗎？不僅不需要改，你甚至都不需要懂這些吧？同樣的道理，車上的各類控制器，就類似于上面的這些驅動，其功能已經(jīng)歷過時間的檢驗，是非常穩(wěn)定的系統(tǒng)了，就算你要開發(fā)新的應用層功能，也別碰這些東西。
其實，大部軟件的功能定義，都可以從整車層面考慮，而不只是應用層。這也是SOA理念的一部分。
九章智駕：總結句下來，SOA理念的核心就是：底層的改動越少越好，將上層模塊化、使其可自由拆解——不光是軟硬件解耦，還有硬件跟硬件解耦、軟件跟軟件解耦。 可以這樣理解嗎？
鄭心航：對的。就是把整個系統(tǒng)的整體功能打散，拆成很多顆粒度更細分的、可以復用的，或者可以重新編排的模塊，然后，通過重新編排就可以實現(xiàn)系統(tǒng)。
九章智駕：看起來，SOA的理念，其實更有助于車企去做正向開發(fā)？之前還沒有SOA的時候，采用怎樣的技術架構就決定了我能實現(xiàn)的哪些功能，一旦技術架構定下來了，功能就很難擴展了；而在SOA理念下，技術架構可以根據(jù)功能來調整的?？梢赃@么理解嗎？
鄭心航：是的。
按照傳統(tǒng)的開發(fā)模式，如果你希望能自動調整車艙內的座椅位置、空調溫度，那你首先得重新定義車內的通信矩陣，然后再讓座椅供應商改座椅控制器的指令、讓空調供應商調試空調熱管理系統(tǒng)的總線。
但在SOA的架構下，你只需一次性把所有的 API 都掛到平臺上，后續(xù)的新功能，就在這個 SOA 之上開發(fā)就行了，下面的控制器就不用變了。
九章智駕：總結下來，之前是“牽一發(fā)而動全身”，現(xiàn)在則是“牽一發(fā)就是牽一發(fā)“而已。
您之前還提到，SOA理念的落地，在很大程度上要通過跨域中間件來實現(xiàn)，而在此過程中，行業(yè)里習以為常的組織架構也將發(fā)生變化。 這個該如何理解？
鄭心航：目前，還沒有任何一個主機廠有一個專門的中央部門來定義跨域中間件，至少是從組織層面還沒有。當然，主機廠也希望我們能把這個跨域中間件做出來，這樣就免得他們內部的部門之間老是打架了。
九章智駕：易特馳的官方公眾號此前提到：易特馳提供一個安全守護模塊，從整車的角度出發(fā)，將各類功能安全的核心控制和維護收歸保作系統(tǒng)層面，智能汽車軟件的開發(fā)者無需對整車功能安全有太強的了解，只要關心自己面向消費者的業(yè)務邏輯即可。
這個該怎么理解呢？
鄭心航：這是易特馳在行業(yè)里率先提出的一個新的開發(fā)范式，其實也是SOA理念的一部分。
在傳統(tǒng)汽車時代，所有的功能安全都是在控制器內實現(xiàn)，即每個控制器都有自己的功能安全等級、有不同的功能安全場景，那每個模塊的開發(fā)團隊都需要掌握功能安全相關知識。
但在“將各類功能安全的核心控制和維護收歸操作系統(tǒng)層面”的理念下，大部分新類型的軟硬件功能都會在SOA平臺或跨域工作平臺上做開發(fā)，而功能安全模塊等底層模塊則會交給整車操作系統(tǒng)層面統(tǒng)一去控制；相應地，各控制器的開發(fā)者也就不需要自己再去操心功能的安全了。
在這一理念下，如果當前處于整車安全模式，則各上層應用就可以調用各控制器；如果當前不處于整車安全模塊，則上層應用就沒法調用各控制器。比如，根據(jù)駕駛員的身高調整座椅位置這個功能，在正常情況下是可以被調用的；但在車速達到30公里/小時以上時，這個功能就沒法調用了。
誠然，不大可能把所有控制器的所有安全模塊都做一個排列組合（這樣很容易失控）；但至少在一開始，我們可以設置2-3個不同的安全模式，在不同的安全模式下，上層應用可以去訪問不同的控制器。
九章智駕：“將各類功能安全的核心控制和維護收歸操作系統(tǒng)層面”這種理念應該可以提高自動駕駛系統(tǒng)的開發(fā)效率，那它有沒有提升安全性呢？
鄭心航：我們的目標是不降低整車的安全性——在確保安全性的基礎上提高開發(fā)效率。
九章智駕：很多公司都在自研中間件，但功能安全模塊并不是他們擅長的。那么，易特馳會考慮將功能安全模塊單獨出售給主機廠或算法公司嗎？還是說，這塊是作為核心競爭力，不會單賣？
鄭心航：功能安全模塊是易特馳提供的整體解決方案的一部分，不會單獨賣。因為，別人只買這一塊的話，也不能很好地發(fā)揮出它的效益。
九章智駕：自動駕駛行業(yè)在過去幾年的實踐已經(jīng)證明，由于芯片平臺和算法都還沒收斂、中間件還不能真正滿足SOA框架的需求，軟硬件解耦一時半會兒還無法成立。在實踐中，中間件先得跟一款芯片平臺深度綁定才行。
這是因為中間件的硬件抽象層很難做，因而難以跨SoC平臺使用嗎？易特馳提供的基礎軟件方案是否能成為“特例”？
鄭心航：這個話題之所以能引起很大的爭議，是因為行業(yè)內不同的人對軟硬件解耦的定義不同、期望值也不同。
其實，當年在AUTOSAR CP 平臺出來的時候，就有人在講“軟硬件解耦”，說自己開發(fā)出來的控制器軟件可以部署在不同硬件上面。
九章智駕：可現(xiàn)在，AUTOSAR CP是“軟件依附于硬件”的典型啊。
鄭心航：你去看它的初始愿景，確實就是軟硬件解耦，只是在這個目標上它沒有成功而已。
九章智駕：那它沒有成功的原因在技術方面還是商業(yè)方面？
鄭心航：兩方面的原因都有吧。
從商業(yè)層面來說，主機廠并沒有期望控制器的盒子向供應商A買，然后對應的軟件向供應商B買。那時，主機廠的采購習慣就是，我找一家供應商，你幫我包了整個系統(tǒng)。
從技術層面來說，在AUTOSAR CP時期，怎么保證供應商B的軟件能跟供應商A的硬件完全兼容呢？即便能兼容，在交給兩家供應商做的情況下，測試驗證的工作量顯然會更大，而這塊工作應該由誰來承擔呢？
九章智駕：現(xiàn)階段，主控芯片變成SoC了，中間件是類似AUTOSAR AP這種，所以，大家在談軟硬件解耦的時候，有一個基本的共識應該是說“中間件相對穩(wěn)定，然后，下面的SoC芯片跟上面的算法‘任意切換’”。
但這個看似“比較基礎”的目標仍然未能實現(xiàn)，原因在于中間件的硬件抽象層沒做好，因而難以跨SoC平臺使用嗎？
鄭心航：自動駕駛車輛上的攝像頭和激光雷達采集到的數(shù)據(jù)都是精度很高的數(shù)據(jù)，為了降低數(shù)據(jù)傳輸的時延，就得通過硬線零拷貝這種非標準的硬件框架來傳，這意味著，數(shù)據(jù)是一定要跟特定SoC的硬件架構綁定在一起的。（零拷貝等技術手段，目前高度依賴于特定廠商的硬件平臺的實現(xiàn)方式，無法與硬件平臺解耦。）
此外，即便是算法跟SoC可以解耦，但數(shù)據(jù)來源于傳感器，而數(shù)據(jù)質量不一樣，算法的表現(xiàn)就不一樣，因而，傳感器型號的變化就會對算法產生很大的影響。那你怎么可能真正實現(xiàn)軟硬件解耦呢？
最理想的軟硬件解耦，應該達到PC行業(yè)這種解耦程度，但畢竟，智能汽車的物理架構要比PC復雜得多，并且還沒有統(tǒng)一的行業(yè)規(guī)范，因此，智能汽車的軟硬件解耦最終能實現(xiàn)的程度應該會跟PC行業(yè)有很大的差距。
九章智駕：所以，聽下來，軟硬件解耦沒有達到預期，它不全是個技術問題？
鄭心航：有技術問題，也有組織問題，但當前來說，更多還是技術問題。
九章智駕：但不管怎么說，中間件最初的“使命”就是幫助實現(xiàn)軟硬件解耦。那易特馳作為中間件廠商，如果產品能幫助下游客戶更好地實現(xiàn)軟硬件解耦的目標，你們的市場占有率會不會大幅度提升？從這個角度來說，易特馳會不會把更好地服務于軟硬件解耦當成一個很重要的目標？
鄭心航：中間件能不能幫助實現(xiàn)軟硬件解耦，這并不是一個非黑即白的問題。
一方面，達到PC行業(yè)那種軟硬件解耦水平，確實不是我們要追求的目標；另一方面，我們也確實相信，在SOA架構下，可以實現(xiàn)上層的應用軟件跟ESP等底層的控制器在邏輯上的解耦。
九章智駕：易特馳的部分基礎軟件和工具鏈是開源的，目前，開源的主要是哪些模塊？這塊的商業(yè)模式是怎樣的？開源生態(tài)的實際進展是怎樣的？開源面臨的最主要的挑戰(zhàn)是什么？
鄭心航：開源的主要是跟云原生相關部分。 所謂云原生，即把傳統(tǒng)IT行業(yè)內原來用于云計算那一套技術棧和解決方案搬到車里面，將其變成一個通用的計算平臺，在底盤域、自動駕駛域、信息娛樂域之間進行一些跨域的數(shù)據(jù)采集、調度及計算；將對功能安全和實時性要求高的模塊跟對功能安全和實時性要求低的模塊解耦。
我們既向那些打算自研的主機廠提供開源的社區(qū)版產品，也向那些更傾向于跟供應商合作的主機廠提供企業(yè)版產品——企業(yè)版的功能安全等級更高，我們也可以根據(jù)客戶的特定車型做大量的適配及驗證、認證工作。
對不開源的部分，我們還可以跟客戶共享IP，但這個是要 case by case去談的。
九章智駕：博世對做標準化、平臺化的產品是有“執(zhí)念”的，但現(xiàn)階段，主機廠對自動駕駛相關技術的需求都是高度定制化的，甚至會“為了差異化而差異化”，那易特馳是如何平衡平臺化跟定制化開發(fā)的關系呢？
如果重心是提高產品的通用化水平，那如何解決適配性和兼容性問題（跟不同芯片、算法及其他公司做的中間件的兼容）？
鄭心航：這是一個關于公司如何定位的問題。
從中長期來說，易特馳是一個產品化的公司，但當前，智能汽車產業(yè)正處于快速變動中，這意味著，在中短期，一定會有大量的市場需求是我們的標準化產品所無法滿足的，因此，我們也愿意為主機廠提供定制化的解決方案。
與此同時，我們也會逐漸地將每家主機廠的特定需求進行提煉，提升它的復用性，然后形成標準化程度比較高的方案。
也就是說，在這個需求還不明確的領域里，我們不能一下子就推出一個龐大的全新的產品，而是在做一個個定制化的項目的過程中來形成未來可復用的能力，并最終形成新的產品。
九章智駕：我們在此前的沙龍上也聽到類似的觀點，就是說，標準化的東西，還是得在定制化內容的基礎上去抽象。
鄭心航：對對對。這也是博世長期以來的成功經(jīng)驗的總結。
九章智駕：我們之前聽一些主機廠的人反映，工具鏈和中間件需要跟主機廠的研發(fā)流程高度匹配，因而只能以服務的形式提供，很難做成標準化的產品。那易特馳是如何看這一觀點呢？
鄭心航：每家主機廠的工作流程都不一樣，為了讓客戶的工作流程跟我們提供的工具鏈和中間件相匹配，我們可能得提供一些工程咨詢服務。
這個工程咨詢服務，就是首先理解客戶的痛點、梳理它的現(xiàn)狀（至少包括技術和組織架構兩個方面），然后再以咨詢方式給它定制一整套的解決方案。當然，這些定制化方案中肯定也包括了大量已經(jīng)很成熟的通用化解決方案。
下載ECAD模型
