無論是封閉的還是開放的，這幾乎在每個行業，甚至在每個企業中都是乙個討論的話題。
現在，東軟睿奇給出了自己的答案：必須開放，必須合作。
華為汽車BU的獨立性，也促使大家思考，整車廠的研發體系該如何去做，如何安排，未來如何達到敏捷性和價效比的最優狀態。 在東軟睿馳總經理曹斌看來，各行各業要有分工合作到一定階段，需要依靠生態解決成本問題和創新問題
他希望，東軟睿奇可以率先把握生態話語權，因此提出並構建了OpenVOC開放技術框架
東軟睿馳希望基於OpenVOC開放技術框架，構建乙個開放、共贏、靈活、高效的創新生態，讓第三方開發者可以更便捷地參與到智慧型軟體的開發中。
當然，這是對現有傳統方式的顛覆，但它也可以產生巨大的能量。
曹斌，東軟睿馳總經理。
未來，會有很多沒有汽車經驗的人，在這個行業中扮演著非常重要的角色”。曹斌以手機為例，稱手機只提供平台和載體，但微信等第三方軟體的影響力比任何手機公司都大。 正是因為發展框架的引入，未來的行業主導地位、話語權、生態模式才會發生根本性的變化
為什麼要引入OpenVOC？
推出新架構的原因顯然是以前的架構不能滿足當下的需求。 具體說來解決汽車行業在軟體開發中面臨的軟硬體解耦難的問題。
多年來，我們覺得'軟體定義汽車'仍然很痛苦。 曹斌認為最深層次的問題是架構沒有達到非常穩定的狀態，軟體開發正規化沒有形成清晰、穩定、迭代的狀態
原因很簡單。 在軟體定義汽車出現之前，或者說在汽車電氣化之前，在傳統的汽車EE架構中，每個部分都是相對獨立的，它們之間的連線也相對簡單。 例如，控制器通過CAN（控制器區域網）匯流排連線，感測器通過模擬訊號連線，執行器通過PWM（脈寬調變）訊號連線。
這樣一來，每家車企都有自己熟悉的Tier1業務、晶元公司等，形成了自己的堡壘，整個行業處於相對穩定的狀態，軟體效率、硬體效率、汽車成本模型都相對穩定。
但也會導致通訊效率低、故障率高、公升級困難等情況
過去，我們在傳統ECU或控制器形式驅動的軟體開發模型上做了很多嘗試。 曹斌舉例說，做乙個整車控制器，**域控還是L2+自動駕駛域控，往往幾百甚至幾千人一起工作，做乙個整車研發軟體需要幾十個小時，如果發現測試不對，就需要重新開始。
同時，即便是整車推出後，1000人的軟體團隊也無法完全解放，因為後續有不斷的迭代工作，以至於很多車企都建立了成百上千人的軟體開發團隊
但在這個階段，這不僅關乎創新、更好的技術和體驗，還關乎成本。 曹斌認為，原有的方法和制度支撐不住，成本與創新的矛盾無法打破，行業壓力會越來越大。
如何解決上述問題？
曹斌給出的方法是：分工合作。 他還認為，未來所有行業都必須有分工合作到一定階段，需要依靠生態來解決成本和創新問題。
如何分工合作？首先要考慮的是建築。
在曹斌看來，汽車的下一階段將是智慧型出行機械人的發展，在這個發展理念下，將有三種硬體形態的配置：人臉，人與車之間的互動介面，即座艙介面;大腦，第乙個承載高效能複雜計算和高安全性基礎邏輯的超級計算大腦;機構，負責執行操作的相關區域控制器。
整體來看，Brain作為計算中間平台，高效連線Face（IVI）和Body（區域控制器），使軟硬體架構充分實現軟硬體解耦，隔離區域控制器的複雜性，降低對IVI算力的需求。
曹斌認為隨著智慧型汽車的不斷發展，FBB硬體配置已成為未來必然趨勢。 東軟睿奇希望打造承載所有計算的一流超算計算機BRAIN，構建一套全新的開發方法和應用框架，實現全分層解耦
在此背景下，東軟睿馳提出並構建了OpenVOC開放技術框架即在晶元上構建“車芯智慧型軟體功能”時所採用的“硬體形態+軟體架構”，其軟體架構更加開放，任何應用都可以通過軟體的服務介面接入汽車上的所有硬體功能，第三方開發者也可以更方便地參與智慧型軟體的開發， 與汽車工程師開放共創
可以理解為，框架應用後，車企和龍頭企業在設計汽車時只需要關注底層軟體和必要的功能應用，上層智慧型駕駛和座艙相關應用軟體就可以交給其他軟體開發商，從而實現快速開發、快速上手、快速迭代
如何更好地實施OpenVOCs？
為了匹配 OpenVOC 開放技術框架，東軟睿智公升級了NeuSAR、智慧型駕駛元件、場景引擎、車雲元件、硬體產品定義等五大元件
首先，針對“下一代E域控制”的系統元件NeuSAR，在OpenVOC的實踐中，對車載訊息匯流排VMB進行了全新公升級，針對自動駕駛的關鍵需求增強了特性，針對車輛不同異構系統、物理匯流排協議和開發系統的統一通訊介面，實現了跨語言開發組合， 並提供統一的介面，用於遮蔽不同通訊場景的物理匯流排和通訊協議。
同時，NeuSAR公升級了Python開發框架，不僅提供了對基礎元件和服務的訪問，還提供了Web服務呼叫方法，通過更好的雲端相容性，靈活處理跨域、跨功能組合的應用軟體開發，並且基於Python的功能特點，更多偏向AI的應用也可以更自由、更簡單地實現訓練資料， 演算法組合等，將應用開發者的程式設計門檻降低到1 2年。
在工具鏈層面，NeuSAR為跨域系統功能提供了統一的基礎軟體配置介面，涵蓋了設計、開發、除錯、部署、測試、整合的完整開發流程，開發者使用該工具的習週期僅需6周。
提供Windows Linux桌面應用和雲Web部署方式，支援基於遠端伺服器的本地USBKEY等多種授權管理方式最新的 Neusar devkit 工具鏈，來自"全部集中在乙個地方"在開發體驗、生態開放性、引導互動、配置覆蓋率等方面進行了全面公升級，讓開發者無需深入了解AUTOSAR即可上手，應用配置效率提公升75%，AUTOSAR方法論知識需求降低80%。
其次，在面向“智慧型駕駛開發者生態”的應用元件方面，東軟睿馳智慧型駕駛應用元件通過預置Neusar軟體開發平台模組，為合作夥伴提供可定製的應用功能架構、配套的元件庫、開發友好的工具，解決80%以上的工程任務。
在這種元件配置下，將原有定製鏈開發的應用演算法架構轉化為基於訊息訂閱和發布的靈活組合，實現了演算法之間便捷的相互呼叫和多種演算法的組合，降低了應用元件之間適配的複雜度，提高了應用功能架構的靈活性。
第三，在車雲基礎設施車雲元件方面，面向“接入非傳統汽車行業新生態應用”，東軟睿馳車雲元件提供NXMQ通訊、數字映象雲、自動駕駛雲工具元件。 形成雲端（雲服務閘道器）-流水線（NXMQ訊息通道）-車端端（車側ECU預定義訊息）直接上雲的元件設計，並提供雲Android、資料化環境、資料化自動駕駛研發工具平台
基於NeuSAR訊息匯流排等模組，可將車側ECU的預定義訊息直接上傳到雲端，並可訂閱呼叫雲端ECU的訊息，將核心算力轉移到雲伺服器，滿足灰度切換和智慧型運維，充分利用和發揮雲平台的彈性和分布式優勢， 釋放本地計算晶元算力，實現分鐘級場景迭代，提高資源的靈活性和可用性。
然後，在面向“車載智慧型場景應用創新”的應用元件場景引擎方面，東軟睿達場景引擎元件通過接入資料、服務、AI等元件，為動態資料、動態服務、動態場景提供全套工具鏈，實現500+指令碼併發，支援灰度發布和雲上服務配置管理。
場景引擎元件通過預置NeuSAR訊息匯流排、Python、WebService擴充套件模組，支援低質量輕量級部署模式下的WebService呼叫，實現SOA應用的靈活部署和高效創新，縮短從設計到工程實現的週期，並可預測使用者需求，避免使用者在開車時不斷切換應用的尷尬。
最後東軟睿奇定義並描述了在人臉-腦體配置中承載智慧型功能的BRAIN產品形態，同時也推出了符合OpenVOC開放技術架構的軟硬體一體化系統產品實踐案例：X-Center 20
x-center 2.0 通過一塊晶元進一步覆蓋多種智慧型駕駛功能，提供 40TOPS AI 算力、200kDMIPS CPU 算力、440 Gflops 3D 渲染算力，支援麥克風、音訊、藍芽、4G網路、語音視覺多模態互動等基礎座艙模組。 結合底層硬隔離設計方案，將座艙域、儀表域、智慧型駕駛域安全隔離，獨立執行。
如何吸引生態夥伴加入？
理想很滿，但如何打破既有格局，讓更多的合作夥伴加入進來，形成東軟生態呢？
對此，曹斌的說法是：解決實際問題，默默滋潤事物。
與一些選擇高的企業不同，我們希望與合作夥伴一起在實踐中打磨技術，形成方法和制度，使他們的開發效率、軟體質量、系統質量得到極大的提公升。 曹斌表示，最終將逐步實現從數量到質量的轉變，並形成正向案例，吸引其他合作夥伴加入。
在曹斌看來，真正能做好全棧自研的車企很少，制度對人才和開放成本的要求非常高。
曹斌認為未來，一旦生態形成，大家接受開放平台的可能性就更大了。電腦也是，手機也是，這些真正做中間平台解決基本層面問題的軟體大多是，最後軟體系統中有很多生態價值創造者，它們整合組合了個性化的應用，這就是商品屬性的最終形態，我想汽車行業會是這樣的。
2024年，大家都在說，未來中國汽車市場的競爭會更加激烈，不僅是國內主機廠，國際主機廠和科技公司也會參與進來，這是今年非常突出的變化。曹斌表示，這也是東軟睿奇在當前時間點提出統一的生態框架和架構的原因。 “其實我想告訴大家，既然自研不可行，就要分工合作，讓框架中的每個定位逐漸變得清晰起來，這樣才能更敏捷地應對創新和成本壓力。 ”
在曹斌看來，中國只有將技術和創新領先優勢轉化為生態優勢，才能在本土工業化競爭中繼續保持優勢。 未來，競爭格局將進入生態建設和生態競爭階段。 “我們希望成為先行者，並在未來佔據更好的位置。”
雖然希望企業之間的分工明確，但在生態建設初期，難免會有重疊的元素。
曹斌說，凡是做生態的，都要解決做某事不做的問題。 “東軟睿奇的核心定位是中間架構、通用元件和可高度復用的工具。 在這個過程中，會有一些硬體參考設計，這些參考設計是為大家量產而製作的，因為現在還為時過早，但當涉及到競爭水平時，我們會保持自己的界限。 ”