當前位置:首頁 > 文章資訊 > 汽修專業 > 汽車軟件工程師-軟件究竟如何定義汽車?從電子電氣架構的演進看軟件開發分工的變化
汽車軟件工程師-軟件究竟如何定義汽車?從電子電氣架構的演進看軟件開發分工的變化
汽車軟件工程師-軟件究竟如何定義汽車?從電子電氣架構的演進看軟件開發分工的變化?
汽車界一直都有所謂的“傳統派”與“互聯網派”之間的話題爭論。傳統派與互聯網派都有自己的優點,但卻是有明確的領域限制的,比如互聯網所倡導的以用戶為中,持續打磨產品和服務的設計理念,對于傳統汽車行業的確有非常大的幫助。
引言:作為一個技術的愛好者,搞算法,玩芯片,攢系統,并不只是工作,也是自己所追求的很重要的部分。寫這個系列,是為了梳理這幾年的所學、所思、所想,從而形成一個完整的知識體系,也供大家參考。這是一個橫向跨度很大的新領域,大家都還在探索,水平有限,難免疏漏,不對之處請大家指正,也歡迎各領域的專家參與討論。
由于自身電子設計和機器視覺的背景,早期的項目經歷,讓我涉獵了各領域的技術,包括電子設計、嵌入式軟件、互聯網全棧、移動端 app、操作系統、渲染引擎、內核驅動、工業控制現場總線等,每一個部分都不敢說有多么精通,但都經歷過實際的項目。對車這個領域,并不是專業出身,之前了解并不多,但為了能理解一幫傳統汽車人在想什么,也是惡補了博世系列的十幾本關于車輛工程、汽車電子、電子電氣架構、動力系統等方面的書。多領域的涉獵也給這個系列的主題,提供了不同的視角。
一、互聯網與傳統汽車人的碰撞
在這個領域探索了幾年,一個感悟就是,百年汽車工業,任何人也不要妄談顛覆,但是也絕對不能拒絕進化。汽車界一直都有所謂的“傳統派”與“互聯網派”之間的話題爭論。傳統派與互聯網派都有自己的優點,但卻是有明確的領域限制的,比如互聯網所倡導的以用戶為中,持續打磨產品和服務的設計理念,對于傳統汽車行業的確有非常大的幫助。但是對于過程中所慣用的敏捷開發,快速迭代,卻并不能完全套用,至少是有一定前提的。敏捷開發的前提有兩個,標準化的基礎設施的支持,并且需要有良好的架構設計。
互聯網領域,部署代碼的主要有,電腦端、移動端、服務端。每個端操作系統、應用開發框架、開發工具都非常標準,但如果是一輛傳統架構的汽車,有幾十上百個 ECU,而且還來自于不同的供應商,系統集成的復雜度不是線性而是指數級別的增加,不得不有一套嚴苛的流程去規范整個開發流程。
二、從電子電氣架構的演進看軟件開發分工的變化
電子電氣架構EEA(Electrical/Electronic Architecture),最先是由德爾福公司提出的。汽車作為一個復雜的電子系統,按照傳統定義,可以劃分為車身、底盤、動力、信息娛樂、輔助駕駛等幾大子系統;每個子系統又由多個電控單元 (ECU)組成,這些ECU連接起來就形成了一個網絡結構;EEA 的主要職責就是定義這些ECU之間的連接方式與網絡拓撲結構。
電子電氣架構
2.1 傳統的分布式的電子電氣架構的問題
網絡結構復雜,形成信息孤島,中央網關會是性能瓶頸
ECU冗余,算力浪費,且無法形成協同
ECU 由不同的供應商開發,框架無法復用,無法統一 OTA
外部開發者無法對 ECU 進行編程,無法由軟件定義新的功能
無法進行硬件升級
2.2 不同架構主機廠扮演的角色
基于傳統分布式架構,主機廠只是架構的定義者,核心功能是由各個 ECU 完成,其軟件開發工作主要是由 Tier1完成,主機廠只做集成的工作,這也是為什么大部分傳統主機廠基本沒有軟件開發能力的根本原因,就靠 DRE搞定供應商就能集成一輛車,為什么還要花大量的成本養一個龐大的軟件團隊。
基于域控制器架構,屬于過渡形態,DCU 減輕了中央網關的壓力,也可以實現部分業務邏輯,但大部分業務還是由各 ECU 實現,主機廠可能會參與部分 DCU 的開發,但與 Tier1的整體分工無太大變化。
基于中央計算的架構,此時大部分 ECU 消失,各種傳感器與執行器,被中央計算單元所支配,原本屬于 Tier1的大部分策略層面的軟件需要由主機廠去主導,需要一只專業的軟件團隊,或者定義某種規范,讓 Tier1實現,最后以軟件模塊的方式集成進來,這需要一只高水平的軟件架構團隊。
2.3基于中央計算電子電氣架構的優點
算力集中到為少數幾個中央單元,可以留有冗余便于后續軟件功能升級
經過良好的平臺化設計之后,硬件單元也可以升級,如特斯拉的 AP
該架構是軟件定義汽車的硬件基礎,并不是有了新的電子電氣架構就能夠實現軟件定義汽車,這還只是萬里長征第一步,還需要有一個經過良好架構設計的基礎軟件平臺。
三、車載環境下的操作系統
提到基礎軟件平臺,很多人的第一反應就是要做一個操作系統,操作系統的確是非常關鍵的一個組件,但是打造一個基礎軟件平臺絕對不是再造一個操作系統。
3.1操作系統的定義
操作系統是一種管理計算機硬件與軟件資源的計算機程序,大眾所知道的其實都是很泛化的操作系統概念,常見的概念分為四個層次。
類型 代表 特點
|
|
|
內核 |
Windows NT、Unix、Linux、QNX、IOS(發源自 Unix) |
有自己獨立研發的內核, |
發行版 |
Android、AliOS、Ubuntu、各種國產桌面系統、AGL |
在內核之上構建了應用開發框架,包管理,核心服務等組件 |
ROM |
MIUI、EMUI、各種 xxx.OS |
在 Android 上修改過了系統服務和系統UI |
中間件 |
ROS、DurerOS Apex.OS |
具有某種功能集合的操作系統中間件 |
3.2內核分類
內核(kernel) 是操作系統最核心的部分,可以理解為操作系統的心臟,分為三種類型:
微內核
QNX、LiteOS、VxWorks
只實現基本的任務管理、內存管理、進程通信等,其他包括驅動等都在用戶態實現
宏內核
Linux、Unix
除了基本組件之外,還有網絡、設備管理、文件系統等放在內核態實現
混合內核
Mac OS
結合了微內核與宏內核的好處
3.3選擇操作系統的核心因素
業務類型:
如果業務有實時性要求,必然需要使用 RTOS,比如航天軍工用的比較多的 VxWorks,車載用的比較多的 QNX。
芯片類型:
使用什么操作系統,往往取決于選擇的芯片支持什么,沒有芯片廠商的支持,一個操作系統走不遠。嵌入式領域是ARM 的天下,處理器類型也決定了使用的操作系統類型,Cortex-A/M/R 用于應用處理器、低功耗、實時處理三個方面。
系統生態:
面向C 端用戶的操作系統,應用生態決定了生死。面向行業的操作系統,比如汽車儀表、自動駕駛系統、網關,C 端用戶是無法感知到底用了什么操作系統,開發者的態度決定了使用什么系統,沒有人愿意在一個工具、庫都支持不全的系統上開發軟件。
3.4車載場景的操作系統選擇
汽車上的絕大部分ECU 都是 AUTOSAR 的天下,有些就是簡單的單片機,甚至都不用跑操作系統。剩下的需要操作系統主要是信息娛樂、自動駕駛、復雜網關、TBOX 等。
娛樂系統,其核心是多媒體和互聯網應用,主要關注應用生態和開發者生態,國內大部分都是Android,少部分AliOS,特斯拉用linux,所以娛樂這塊兒國內做的更好,但這并不是他的核心競爭力。由于生態的問題,針對車載的娛樂系統去開發一套操作系統,沒有實際意義,以車的體量,也撐不起這樣一個生態。這一塊兒跟著消費電子走就行了,任何鼓吹系統底層能力的行為,都是隔靴搔癢,沒有搞清楚重點。
自動駕駛,其核心是算法設計和數據積累,沒有人會把算法的軟件實現和操作系統綁死,其設計一定是跨平臺的,有成熟穩定的 RTOS 即可,目前主流的有三種 RT-Linux、QNX、VxWorks。由于深度學習構建在開源軟件的基礎上,也需要生態,這也是linux 雖然不是硬實時系統,但依然在自動駕駛領域用的比較多的原因 。自動駕駛這塊,倒是缺一個類似于 ROS 的能夠跨平臺的分布式開發框架 ,雖然ROS2進化許多,但是在低延時、功能安全、信息安全方面還有很多路要走,國外有家創業公司APEX.AI,正在基于ROS2分支,把它往車規級方向做。NVIDIA 構建了一整套的框架,做的非常不錯,但是和自家芯片綁死,限制了其使用范圍。
網關以及以后的大吞吐的以太網交換機,雖然算力要求也高,但是任務相對單一,架構也很簡單,現有系統就能滿足,也沒必要去開發一個針對網關的操作系統。TBOX由于主芯片來源單一,目前基本是都是 Linux。
經過以上的分析,大家可以知道,目前根本就不是因為操作系統的短板限制了軟件化的水平,車載架構的特殊性,決定了無法使用單一操作系統來實現所有功能,多個操作系統并存的局面還會持續很久。
四 中央計算電子電氣架構下的基礎軟件平臺
前面提到,新的電子電氣架構是軟件定義汽車的硬件基礎,并不是有了新的電子電氣架構就能夠實現軟件定義汽車,還需要有一個經過良好架構設計的基礎軟件平臺。下面我們就來對這個問題進行重新定義。
4.1 問題描述
在新的電子電氣架構下,多個中央處理單元、多個傳感器、執行器、交換機等,在以太網的連接下,組成了一個復雜的分布式系統 ,由于工作任務的不同,多個中央計算單元運行著不同的操作系統。
4.2 核心訴求
“軟件定義汽車“,其核心內涵就是,能夠通過軟件的方式,動態改變上述系統當中網絡節點之間的聚合關系,從而產生新的業務功能,因此對軟件平臺的要求如下:
既然是軟件平臺,就應該不依賴于特定操作系統、芯片、車型,因此硬件抽象是最先該考慮的事情。
能動態改變聚合關系,就要求網絡中的節點之間的連接關系是可以運行時更改的,同時每個節點應該具備高內聚、低耦合的特性。
需要滿足車載環境高可靠性、實時、安全性。
搞互聯網后端的或者 IT 系統的人,看到“軟件定義汽車“的描述,第一反應可能是,這不是就是我們搞微服務架構的思路嗎?
這就是我想說的第二點,互聯網的開發流程雖然不能直接套用在車上,但是其在軟件工程領域的實踐經驗對于解決車載軟件領域的問題還是很有幫助的。看起來是汽車電子軟件開發的門檻高,其實是因為封閉和從業人員少。當前的機遇就是,大家都想往這個方向走,但是也都是摸著石頭過河,可以有機會將這些理論經驗用于實踐。
前段時間梳理了一下,面向下一代智能汽車的關鍵技術,分為智能座艙、自動駕駛、與數字系統。今天講的主要數字系統當中,我認為最重要的軟件基礎設施,基礎軟件平臺,下一篇將重點闡述,面向服務的架構設計與車載軟件相結合的一些思考, 以下思維導圖僅供參考!
智能座艙
以產品設計為驅動力,但目前同質化現象比較嚴重,主要以硬件差異為基礎,只能利用先發優勢,無法形成技術與產品壁壘!
基于用戶畫像,使用AI技術,構建具有情景感知能力的引擎,是智能座艙產生質變的前提,但技術上短期無法突破(行業普遍問題,不是車行業特有)。
多設備協同、多模態融合交互,是消費電子IOT場景下大家探索的方向,對于車載環境有很強的借鑒意義。
自動駕駛
以算法與數據的積累為核心驅動力,可以在技術上形成壁壘,但是需要巨額的研發投入,能否快速落地主要受制于數字系統架構。短期來講大家可能都差不多,但是積累到一定時間,后發玩家可能就再也追不上了。
數字系統
以架構設計與資源整合為核心驅動力,其包含了傳統意義上的電子電氣架構,但需要橫向整合多個軟硬件架構部門,才能定義完整的系統架構。是否采用新架構從根本上決定了,智能座艙與自動駕駛究竟能走多快走多遠。
良好的數字系統架構,能夠屏蔽底層車型平臺的差異,多個車型共用一套基礎軟硬件平臺,能夠縮減開發資源,一套架構持續5年,可以留出充足的資源研發下一代。
本文作者:leo_huang_
本文系作者投稿文章,任何形式的轉載都請聯系作者獲得授權并注明出處。
以上就是100唯爾(100vr.com)小編為您介紹的關于汽車電子的知識技巧了,學習以上的汽車軟件工程師-軟件究竟如何定義汽車?從電子電氣架構的演進看軟件開發分工的變化知識,對于汽車電子的幫助都是非常大的,這也是新手學習汽修專業所需要注意的地方。如果使用100唯爾還有什么問題可以點擊右側人工服務,我們會有專業的人士來為您解答。
本站在轉載文章時均注明來源出處,轉載目的在于傳遞更多信息,未用于商業用途。如因本站的文章、圖片等在內容、版權或其它方面存在問題或異議,請與本站聯系(電話:0592-5551325,郵箱:help@onesoft.com.cn),本站將作妥善處理。
汽車電子課程推薦
汽修專業熱門資料
汽修專業技術文檔
推薦閱讀
