今天小編分享的汽車經驗：本土化汽車作業系統的發展路徑與落地實踐，歡迎閱讀。
随着汽車行業向軟體定義的方向發展，作業系統成為驅動汽車智能化發展的重要組成部分。
現代汽車作業系統不僅需要管理底層硬體的驅動程式，還需要提供豐富的功能和服務，如車載娛樂系統、導航系統、安全系統、智能駕駛輔助等。這些功能和服務的復雜性和規模日益增長，給汽車行業帶來了前所未有的挑戰。
近幾年來，随着國内汽車產業的快速發展，本土化汽車作業系統的發展與落地成為行業關注的重要話題。
為了能夠深入了解當前本土化汽車作業系統的發展狀況，雷峰網新智駕邀請東軟睿馳首席科學家李冰先生做線上直播分享。
下面是分享内容，新智駕做了不改變願意的整理：
大家好，我是東軟睿馳的李冰，十分感謝新智駕的邀請，能與大家分享我們在本地化汽車作業系統發展過程的探索。
行業背景
汽車作業系統是一個非常大的概念，不同組織尚未形成統一的認知。
我們首先看一下整個行業的發展，這個圖是汽車的架構發展情況，我們關注的 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 詳解》。
