圖片來源於網路
L1-L2的自動駕駛，往往是在分散式EE架構下實現，每個功能演算法對應著一顆獨立的晶片，而這些功能演算法又比較簡單，自然用不著高效能的晶片，MCU（微控制器）就可以了。這些MCU上跑的是Autosar Classic Platform（簡稱Autosar CP）等RTOS。Autosar CP相當於包括了核心+中介軟體在內的一套完整的作業系統，儘管功能等級較低、侷限性很多，但似乎已經“夠用”了。
簡單地說，傳統ECU承擔的功能有限，執行相對簡易，如感測器處理只涉及簡單的、解析度較低的點雲或數字影象等，往往只需要排程某一單一任務，因而並不需要高效能的OS來實現資源的排程和分配。
更關鍵的是，在這個階段，功能演算法跟MCU是高度耦合的，主機廠從供應商那裡買來的MCU，往往自帶了演算法，主機廠只需要做好整合工作就行了，無需自己寫演算法，因而，自然也沒有動力去關注作業系統。最大的“客戶”都不著急，那創業者和投資人的動力又從哪來呢？
相比之下，從L2+往上，功能演算法變得很複雜了，分散式EE架構已不能滿足需求，必須要基於集中式EE架構來做開發，而在集中式EE架構（域控制器、中央計算平臺）下，多種演算法跑在一顆類似於Xavier這樣的系統級晶片（SOC）上，大量的資訊需要收集到域控制器上，然後進行感知、計算、決策，資料的傳輸和融合，要比在分散式架構下複雜得多。在這種情況下，SOC晶片需要處理的資料量呈現指數級增長，並且其涉及的任務量也更多，很多工還是多執行緒同時排程，這就需要有一個足夠強大的實時作業系統才能更好地分配、排程運算和儲存資源。
此外，SOC和MCU儘管扮演的角色類似，但前者實現功能安全的難度要大得多（演算法的安全性、資料的實時性等）——MCU僅適用於需求清晰、對算力和時延要求都不高的簡單場景，相應地，跑在其上面的ROTS只需要提供一些排程機制、處理一些簡單邏輯就可以了；而智慧駕駛SOC需要應對的是複雜場景，系統的演算法複雜、功能豐富，有務動態部署，這時，Autosar CP已經無法滿足要求，高效能的作業系統逐漸成為開發者們的“剛需”。
更重要的原因是，無論是特斯拉、蔚小理，還是國內其他主機廠，或者Tier 1，大家的硬體框架基本上已經確定下來了，基於硬體能實現的功能也已經基本確定，無論晶片用的是誰的，能實現的功能基本也就是影象感知等，因此，大家在追求差異化時也自然就把重心放在了軟體的差異化上。
當大家開始關注軟體差異化的時候，軟硬體解耦便會成為必然選擇，不管有沒有能力，凡是有進取心的主機廠都不願再接受供應商提供的“軟硬一體化方案”。在“軟體定義汽車”的大背景下，主機廠必須往下沉，要自研軟體演算法，要能夠定義功能、開發差異化應用，要實現OTA升級，否則就會錯過車輛全生命週期裡最重要的價值。而要做到這些，就不能不關注作業系統。
多位受訪者都指出，從智慧手機產業的歷史來看，在產業發展的早期，通常是作業系統跟著晶片廠商走，在整機廠（手機廠製造商、汽車製造商）買晶片的時候，作業系統已經“配好了”——在這個階段，作業系統怎麼選，更多地是晶片廠商們需要關注的問題，下游的整機廠不需要“操太多心”；但隨著產品成熟度的提升，作業系統的重要性也一步步凸顯出來。
從自動駕駛的需求來說，晶片解決的是“能不能”的問題，而作業系統解決的則是“好不好”的問題。在“能不能”的問題尚未解決之前，“好不好”自然不是一個迫在眉睫的問題；而一旦“能不能”的難關被攻破了，“好不好”自然就上升為“當前的主要矛盾”。
簡言之，在自動駕駛行業發展的早期，是晶片廠商帶著作業系統飛；但隨著產業逐步進入成熟期，作業系統的話語權會越來越大。多位受訪者都認為，到後面某個階段，產業發展高度成熟，開發者高度集中的時候，作業系統的市場集中度會非常高。
