0
隨著汽車行業向軟件定義的方向發展，操作系統成為驅動汽車智能化發展的重要組成部分。
現代汽車操作系統不僅需要管理底層硬件的驅動程序，還需要提供豐富的功能和服務，如車載娛樂系統、導航系統、安全系統、智能駕駛輔助等。這些功能和服務的復雜性和規模日益增長，給汽車行業帶來了前所未有的挑戰。
近幾年來，隨著國內汽車產業的快速發展，本土化汽車操作系統的發展與落地成為行業關注的重要話題。
為了能夠深入了解當前本土化汽車操作系統的發展狀況，雷峰網(公眾號：雷峰網)新智駕邀請東軟睿馳首席科學家李冰先生做線上直播分享。
下面是分享內容，新智駕做了不改變愿意的整理：
大家好，我是東軟睿馳的李冰，十分感謝新智駕的邀請，能與大家分享我們在本地化汽車操作系統發展過程的探索。
汽車操作系統是一個非常大的概念，不同組織尚未形成統一的認知。
我們首先看一下整個行業的發展，這個圖是汽車的架構發展情況，我們關注的E/E架構變革所帶來的軟件變化情況。
回顧軟件的發展歷程，要實現軟件的高質量和低成本，唯一的路徑就是復用。軟件復用需要有一套統一的體系，主要是指開發體系，這個其實是靠不同層級來實現。
對于汽車E/E架構而言，傳統以嵌入式為主的這種分布式架構，比較難實現高層級的軟件復用，大部分都是由供應商來提供整套軟硬件，行業也在使用一些統一的軟件基礎架構，典型代表就是AUTOSAR，它的主要目的就是為了統一的進行軟件的底層設計，提供一些通用的軟件模塊。這個國外發展比較早，國內大概從2016年開始慢慢熱起來。
因為供應商提供整套軟件，OEM對這一塊有比較強的約束，所以AUTOSAR沒有達成其它IT行業的統一軟件平臺概念。
傳統的車機系統和車內系統存在割裂，一般車機系統以安卓為主，車內和車機系統交互沒那么多。
發展到域控制器架構，POSIX成為新的創新點。我們發現無論針對中央域還是智駕域，都屬于POSIX系統，包括有一些好的創新功能，都在這個系統里面來做。
然而在不同的操作系統下做開發和協同，效率不是很高，然后在域控接口中這種跨核的協同要求越來越多，因此行業需要一種更好的開發方式。
那前面說了一些行業背景，這也是一個新的操作系統誕生的時機。 回顧過去，操作系統基本都是在行業變革期出現。舉個例子Linux和UNIX，初衷是為了解決在處理器上并行的問題。
由于操作系統會和生態的關系特別緊密，它會形成強者恒強的馬太效應。一旦進入行業穩定期后，很難替代成型的操作系統。
目前中國汽車處于產業變革期，大算力芯片給應用開發帶來更多的擴展性，傳統MCU開發功能特別有限，大算力芯片可以開發更多更好的功能。隨著域控制器逐漸成為主流，軟件將會發揮越來越重要的作用。
我們講的開發視圖就是與工作臺的交互，主要在于通信矩陣，它很少參與具體模塊的定義和模塊開發，但是它們是和消費者直接接觸的，能更好感受消費者的需求。針對這種情況，越來越多的車企會主導軟件的設計和開發。
新的應用，新的硬件體系，需要新的開發方法，現在就是一個適合的時間點。
在新的技術變更和行業發展趨勢下，汽車原有的開發生態發生顛覆性的改變，傳統的開發模式已經不能滿足市場對整車開發速度及功能迭代要求。
整體復雜度高，軟件復雜度高，同時傳統的組織架構 可能對于新架構可能都不是特別適應，包括我們說的一些開發方法都不一樣。
針對這種情況，新的平臺能夠解決這個問題。主要體現在兩個方面：承上啟下、繼往開來。
承上啟下
SDV趨勢下，底層硬件高速發展，應用需求日新月異。需要中間件層軟件做好上下層的銜接。
對上（應用）：提供標準中間層框架，為應用迭代開發提供基礎。
對下（硬件）：提供標準設備驅動模型，與硬件互相促進，形成“摩爾定律”。
繼往開來
作為基礎軟件通用標準，AUTOSAR架構提供了穩定的底層平臺及開發方法學，但有些跟不上國內SDV高速發展。新的中間層架構要考慮到標準平臺的平穩發展，需要做到：
兼容過往：兼容標準AUTOSAR架構，復用現有的大量經過驗證的核心控制和應用。
支撐未來： 提供新的功能與特性，支撐新形勢下多核異構硬件體系，跨域協同一體化的應用開發需求。
針對本土汽車操作系統，也是有一些策略的。首先構建面向新應用領域的開發架構。在既有成熟體系上，構建承上啟下的應用開發框架，同時在解決問題的過程中，發展自己的生態體系。
第二、推動基礎模塊的本土化替換。以前的一些有積累的企業，可能因為沒有歷史機遇，沒有把知識轉化為汽車類產品，現在機會來了。所以我們應該推動符合汽車功能安全需求的微內核操作系統的國產化替代。針對上面提到的AUTOSAR架構，我們可以自己定義一些中間件。
第三、與本土芯片企業合作。形成國產操作系統和芯片的組合方案，并實現對新應用框架的良好適配，才能夠獲得占領市場的機會。
接下來我們看看國產汽車操作系統面臨的挑戰。
首先從狹義操作系統看，面臨的主要問題是生態不足，生態可以分兩塊，一塊是針對芯片的支持。另一個是缺乏與內核配套的開發工具，比如像性能調試工具。
AUTOSAR標準產品方面，標準不一致，產品穩定性不夠成熟，功能安全和信息安全支撐能力不足，工具鏈易用性及完整性急需提高。
中間件方面，目前處于百家爭鳴階段，技術路線不統一，未達成行業共識。沒有跨核、跨域協同的中間件產品，缺乏面向域控制器的專用中間件標準組件，缺乏整車視角的開發工具鏈。
從整個行業看，軟件力量比較分散，最近兩三年可能會好一些，每個主機廠都會希望自己做一套這種從上到下全能，符合OEM自己的一套系統，這樣就造成軟件力量的分散。隨著行業軟件的發展，我們發現分工才能促進各自在不同領域的效率提升。
另一個就是人才不足，我是從前年開始就發現，每一家車企，包括供應商團隊人才都是比較缺的。尤其是軟件+整車的復合型人才。
芯片問題我們之前講了，操作系統或者內核，芯片的支撐是非常關鍵的。如果沒有這個支撐，其實它也沒法用。雖然中國半導體市場需求旺盛，但是汽車芯片自給率不足5%，國產芯片裝車率低。比較好的就是我們在這一塊正在逐步加強。
最后就是標準，我們之前使用AUTOSAR的時候，發現國外的標準上投入確實挺多的，但是國內缺乏統一的標準。最近國內的標準也在加強，包含行業的組織，民間的組織也在不斷推進標準的建設。
我們首先看到應用的創新和快速迭代，已經成為我們國內行業的核心競爭力。我們的感受尤其明顯，無論是車型的推出速度，還是軟件的更新速度，都是越來越快。
我們作為行業參與者，大量從業人員為了應對創新和快速迭代，大家都在一種高負荷的工作狀態。
針對這種現狀，我們認為“集中式”開發是實現智能汽車核心競爭力的有效方法。
對比傳統的多控制器同時開發，“集中式”開發的速度更快，更容易實現一次開發多車型通用，在OTA指標、代碼量、開發方式、開發效率等外在表現價值方面來看尤為明顯 。
另外就是代碼增長趨勢，目前智能汽車軟件代碼已經到1億行，年均符合增長率約為21%，呈指數級增長，預計到2025年，智能汽車代碼量將達到7億行。
軟件如果不是集中式開發，不是在統一的體系中開發，實現軟件復用和迭代會很困難，而且后續維護成本完全不可控。所以集中式開發對于整個項目的成本控制，有非常大的提升。
針對前面說的發展需求，一個是創新速度，一個是開發成本，我們是需要長期重點解決的，而多域融合是解決問題必須的需求。
多域融合大概分為以下幾個方向:
第一個是整車抽象，當然這個抽象我們提了好久，有的也叫原子服務，有的叫整車功能API化，它就是為了支持SDV的落地。它的核心不在于功能怎么定義，在于承載功能的運行框架，就是你開發者如何進行調用，這是非常關鍵的。
第二個就是容器化部署，就是應用之間的開發不是強耦合的，可以靈活在異構OS上快速移植運行。
分布式軟件實體和基礎框架融合，這些都是為集中式開發提供基礎。
前面我們講了需要為開發者提供的功能，下面講講這一塊的實踐。
針對標準化組織的引入，我們在AUTOSEMO下面成立了一個工作組，主要是為了解決低功耗下，這種廣義操作系統的一些問題，目前大概有30多家企業參與。
除了針對組織外，我們東軟睿馳也有針對行業變革的探索產品NeuSAR，我們提供一個廣義操作系統，為使用者提供一些基礎性的工具，它包含有標準的AUTOSAR、APCP產品，支持傳統的ECU開發，同時又對基于域控制器和新E/E架構的軟件開發提供豐富的基礎軟件、跨域中間件和開發工具。
NeuSAR SF(Service Framework)主要解決跨域融合的問題，兼容ASF標準的SOA中間件，并提供多于ASF標準的功能，支持基礎服務的同時，把開發視圖從域控制器層面擴展到了整車層面，是支撐整車SOA的關鍵組件與落地架構。比如說診斷，診斷在外部看是一個節點，但是從內部看有A還有M系數，不同的診斷路徑就需要一個協調統一的中臺。另外像域控制器的時鐘服務、日志融合等都需要這種中間件。
整車層面也需要這些基礎的服務， 比如日志系統，收集整車日志放到云端進行分析，云端會根據結果下發一些控制指令。
這些都是我們國內開發者需求比較多的，也是創新點比較多的地方。我們認為這套組件可以抽象成標準的基礎服務，對開發者的效率有很大的提升。
最后就是基于NeuSAR相關的工具鏈，第一個叫NeuSAR Creator，我們發現好多功能需要A核和MCU一起開發，如果是傳統的開發方式，需要使用兩個工具，分別配置，分別生成代碼，也可能需要雙關系代碼框架，需要換一種工具進行編輯，換另外一種工具進行編譯。在工具的切換上花費大量時間，而我們將這些功能都放在一個開發視圖，不用頻繁切換工具，節省時間提高效率。
第二個就是調試與測試工具，典型的就是針對以太網的調試，這類工具不是特別多，而且價格特別貴。
最后就是仿真工具，特別是在自動駕駛領域，特別需要總線級的數據記錄或者回放功能。在不同的車型、不同的硬件下，目前還沒有統一的一套仿真系統。基于我們自己的這套仿真系統，只要總線支持不同系統，支持不同芯片，包括不同的物理通信總線，它在可以提供一套統一的語義來進行數據的錄制和回放。
最后NeuSAR是我們的一個基礎產品，到去年已經更新到第四個版本，也是得益于國內行業發展，給我們提供了好多機會，從最開始只做AUTOSAR AP產品，發展到整車級。這里也要感謝給我們提供需求、提供鍛煉環境的車企，還有好多合作伙伴，給我們提供支持。
以上就是今天分享的內容，謝謝大家！
Q：基礎軟件對于廣義和狹義操作系統而言，有什么區別？
可以這樣理解，狹義單指操作系統的內核。然后基礎軟件這個概念，在頭幾年專門指AUTOSAR這種CP產品。新形式下，基礎軟件會和狹義操作系統構成廣義操作系統。
Q：為什么一定要用AUTOSAR的體系，SOMEIP、DDS這樣的協議直接用于實現部分域功能，甚至整車SOA，有什么問題？
那個首先回答一下為什么使用AUTOSAR，因為 AUTOSAR 這個體系已經提供了大量的、成型的功能，它提供的基礎層是比較充分的，大量的應用也是基于AUTOSAR CP開發的。它也是占了一個先機，已經成為了事實上的行業操作系統，已經有大量的生態，想要替換非常困難。
另外就是SOMEIP、DDS用于整個SOA的問題，首先SOMEIP、DDS基于以太網來做會更短一些，針對總線而言，支持不是特別多。另外就是DDS挺“重”，它在M系統上跑起來挺難的。SOMEIP比較死板，所有的東西都是先配置，這種對于傳統開發接受程度高，但是對于自動駕駛這種開發需求而言，接受度特別低，喜歡比較靈活的和簡單的接口。我們也是考慮到不同的開發者需求，提供兼容SOMEIP和AUTOSAR的接口，能夠兼容不同的系統，支持bu一些開發需求。咱們前面提了，叫繼往開來。
Q：老師能解釋一下NeuSAR SF的功能嗎？
簡單來說它就是解決跨域融合問題，針對不同域控制器之間的統一開發。這個主要是為了解放開發者，讓他們不用把大量時間精力花在底層硬件適配上，讓他們把精力換在能直接創造用戶使用價值的應用上。
Q：老師能介紹一下車載操作系統的OTA模塊？
OTA其實不是一個新技術，隨著域控制器發展，目前都叫整個OTA，就是說整個所有的控制器都可以用它升級。這里的難點就是前面提到的集中式開發。
很多時候我們發現難點不在于OTA本身用什么協議，升級鏈路等等，這些都是可以窮舉的。真正的難點在于整車軟件的統一版本控制。這就需要集中式開發，集中式就相當于有統一的開發視圖。回到OTA本身，它只是提供了升級的路徑，但是OTA方面得提供針對版本的統一管理。隨著車型的增多，可能每個車型上的軟件也存在版本差異，比如控制車門的算法可能都不一樣，這需要OTA提供版本管理功能。
Q：老師可以講講車載以太網架構嗎？
車載以太網主要差別就在于二層，三層以上的協議和IT行業基本一樣，這些差別用戶感知不多。這一塊可以去看經典書籍，像《TCP/IP詳解》。
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
