詳解汽車軟件工程師的職位類別及其發展前景
發布日期:2021-04-20 瀏覽次數:2538
最近有不少初入職場的朋友,向我咨詢汽車軟件工程師的職業發展與選擇。剛好我想寫一篇文章談談這個問題,順便寫一些自己作為軟件工程師和項目主管這些年來的職場感悟,最后給出一個非常主觀的選擇排行。
入行這些年,我陰錯陽差地當過通信診斷工程師、算法工程師、需求工程師、測試經理,現在是項目負責人,帶著一個美、德、印三地十來個工程師的軟件工程團隊。也算是有一定發言權吧。可能有些觀點大家不一定贊同,就算是我拋磚引玉,還望輕拍。
正文
首先要澄清一個錯誤的觀念,那就是:不是只有寫代碼的工程師才叫軟件工程師!事實上,車企(零部件企業也好、主機廠也好)的軟件部門里,有一半以上的工程師是不寫代碼的,但是職位也叫“軟件工程師”。
軟件部門組織架構圖:
軟件部門組織架構
一個汽車軟件部門,至少要有以下幾種職位:
-
項目組長
-
需求工程師
-
軟件架構師
-
基礎軟件工程師
-
應用層軟件工程師
-
系統集成工程師
-
測試工程師
那么對新人而言,究竟什么是好的職位呢?我覺得可以從以下幾個維度來考察:
-
能常常學到新知識(成長性):這個不說了,新人最重要的是學習
-
學到的知識在行業里有通用性:這樣才好找下一份工作不是?
-
職位有靈活性,容易轉崗:誰也不會在一個職位上干一輩子。
-
工作過得舒心,同事能尊重,自己有成就感
-
在公司里有曝光度,老板、同事能看得見你的工作:升職快啊。
-
錢多:簡單粗暴。
還有一個維度是工作的穩定性,但是我個人認為這些職位的穩定性都差不太多,而且現在企業裁員都xjb裁,誰去誰留真的不好說,跟員工個人也有很大的關系。所以這個維度就不比較了。
我們現在一個一個說。
汽車軟件開發流程和職位示意
1.項目組長:負責整個項目的總體規劃、任務分配、資源整合、客戶對接,定義任務優先級,在技術路線發生爭執的時候做出決策,并監督整個項目的進行。用人話講就是一個“對外忽悠客戶、對內忽悠組員”的職位。
基本上在軟件團隊里,這個職位是最好的,但是跟職場新人也是基本上絕緣的。你不把技術、流程用幾年時間理清楚,咋能出去忽悠人呢對吧。所以這個職位新人基本上就不用關心了。
-
成長性: 5
-
知識通用性:5
-
轉崗靈活性:5
-
工作成就感:5
-
曝光度: 5
-
工資: 5
綜合評價: 5 -- 少年你還在想什么呢?
2. 需求工程師:和客戶溝通軟件需求,討論確認所有技術細節,并撰寫詳盡的需求文檔。
坦白而言,說需求工程師是一個項目最重要的職位也不為過。一份準確、清晰的需求文檔是一個優秀項目的基石,而一個優秀的需求工程師團隊更能夠直接大幅提升整個項目的效率,甚至能引導整個項目組以最優的路徑開發。需求工程師本來應該是由經驗豐富的老工程師擔任的。
但是呢,需求工程師同時也是一份非常枯燥的工作。平時有一半以上的時間都在寫文檔。如果你足夠不幸, 那還得在一個叫DOORS的挨千刀的軟件平臺里寫,可以寫得你懷疑人生。
IBM 需求管理軟件DOORS
技術大牛們當然是不屑于寫文檔的啦!所以國內外的現狀就是“鳩占鵲巢”:技術大牛負責和客戶溝通需求,而需求工程師們退化成了一幫“打字員”,只是記錄技術大牛的討論和設計,把它們被動地變成需求文檔。
于是需求工程師往往就由新人來擔任,在外企的話,甚至整體外包到印度、越南、羅馬尼亞等等低工資國家去完成。由于新人或者外包團隊對產品理解有限,往往寫出來的需漏洞百出,于是被大牛懟簡直是需求工程師的常態...總而言之這簡直是軟件團隊里最糟糕的一個職位。
由于需求工程師不接觸代碼,也不接觸算法細節,很難轉崗到別的職位。需求工程師的成長路線往往是向系統工程師、質量工程師、安全工程師上靠,最終脫離軟件部門。另外,非常優秀的需求工程師也是有機會成為項目主管的,但往往這種優秀工程師都不是一畢業就做需求出身。
-
成長性: 4
-
知識通用性:3
-
轉崗靈活性:3
-
工作成就感:2
-
曝光度: 3
-
工資: 3
綜合評價: 3 -- 短期做做挺好,別做久了!
3. 軟件架構師:負責軟件架構設計,明確各個軟件模塊之間的接口,并且負責操作系統的配置和調度。
這又是一個和新人無關的崗位。不多說了。能干這個都是技術大牛,甚至比項目主管還牛,因為畢竟不是每個搞技術的人都想去做撕逼搶資源的協調工作。
軟件架構師轉項目主管是理所當然的事,甚至在不少項目里,架構師本身就是項目主管的備份。架構師幾乎可以轉軟件部門的任何職位。
架構師的常用工具軟件:Enterprise Architect
-
成長性: 5
-
知識通用性:4
-
轉崗靈活性:5
-
工作成就感:5
-
曝光度: 4
-
工資: 5
綜合評價: 4.7 -- 和項目組長不相上下的選擇
4. 基礎軟件工程師:其實基礎軟件工程師還可以再細分。包括軟件驅動工程師、通信/診斷工程師等等。驅動工程師就包括Hardware/ECU Abstraction Layer的設計和編程啊、Bootloader編寫啊、AutoSAR的配置啊、內存Layout的設計啊、操作系統啊等等,范圍很廣。而通信診斷工程師就是字面上的意思:負責總線通信接口的配置和診斷的配置。
驅動工程師其實蠻吃香的,尤其現在AutoSAR是個熱門,知識通用性很好,因為各個ECU其實驅動部分的開發都差不太多。但是底層軟件跟ECU的具體功能離得蠻遠,并不容易轉成算法工程師。驅動的測試和軟件應用層的測試差別比較大,所以也比較難轉成整體軟件的測試工程師或者測試經理。
另外,雖然知識通用性好,但是驅動工程師的市場需求總體來說是比較小的。因為一個ECU軟硬件平臺定型以后,基本上驅動部分未來3到5年都不會進行大規模開發了,而是成為一個平臺解決方案,被各個項目借用,所以驅動工程師團隊并不需要很大,這意味著一旦失業可能還是不如其他職位好找工作。
-
成長性: 4
-
知識通用性:5
-
轉崗靈活性:2
-
工作成就感:4
-
曝光度: 3
-
工資: 4
綜合評價: 3.7 -- 我覺得還行
5.通信/診斷工程師:這也是我進入汽車行業的第一個職位。怎么說呢。。。真的超級枯燥且沒有成就感。這也是我在做了兩年多以后選擇跳槽的主要原因。通信/診斷容易上手,適合新人。市面上絕大多數車企都用的是CAN通信和UDS診斷協議。如果做德國車企項目的話,再看看FlexRay就可以了。
然而通信/診斷職位在技術上沒有太大上升空間,雖然知識通用性很好,不愁找工作,但很難接觸ECU的核心功能算法,算是對職業發展有一定的限制。通信/診斷工程師是可以轉成測試工程師的,但是幾乎不可能成為總體軟件的架構師或者項目主管。
而且由于上手快,工資也不是特別有競爭力。
-
成長性: 3
-
知識通用性:5
-
轉崗靈活性:3
-
工作成就感:3
-
曝光度: 3
-
工資: 3
綜合評價: 3.4 -- 有點雞肋啊,還是盡量轉崗吧
6. 應用層軟件工程師:在很多公司也被叫做算法工程師或者控制工程師。我之前做過很長一段時間的轉向助力算法工程師和制動系統算法工程師,這段經歷是最讓我獲益匪淺的。
應用層軟件工程師的主要工具之一:Matlab/SimuLink
應用層軟件,算是ECU軟件核心中的核心。無論是什么控制系統,都可以通過對應用層軟件的設計獲得非常深刻的理解,成長性自不必說。對于通用性而言,只要是算法工程師,招聘時候并不太關心你以前是不是做同一個ECU的,因為應用層軟件都有它的相似性。但是有一點需要注意,那就是ECU的安全等級。
總體來說,高安全等級ECU (比如轉向、制動、安全氣囊控制器)的應用軟件工程師,比低安全等級ECU(車載娛樂系統、車身控制——雨刷、車窗等等)的工程師,在找工作的時候有更大的優勢。這一點我們可以后續再談。
成就感爆棚也是應用層軟件工程師的一個特點。應用層軟件工程師基本上都有機會實車測試并調試自己寫的算法。看著自己的算法從一行行冰冷的代碼,變成能夠跟駕駛員交流的實際功能,這種成就感是其他工作(哪怕是項目主管)都很難帶來的。
另外,由于應用層軟件工程師需要參與V型流程的全過程,基本上可以轉成任何其他的崗位,轉型架構師或者項目主管也是水到渠成的事。
-
成長性: 5
-
知識通用性:4
-
轉崗靈活性:4
-
工作成就感:5
-
曝光度: 4
-
工資: 5
綜合評價: 4.5 -- 對于職場小白最好的出道選擇!沒有之一!
7. 系統集成工程師:負責將每個工程師的軟件變更正確地集成在一起,形成新的發布軟件。系統集成的具體工作就涉及到SCM (Software Configuration Management) 的部分了,比如有的公司用SVN,新潮一點的公司用git , 還有的公司用一些奇奇怪怪的工具(ClearCase, AllChange...) 等等等等。一般而言,除了巨無霸公司有專職的系統集成工程師,一般這個職位是其他工程師兼任的。
ClearCase, 集成工程師要給每個模塊定義好不同的分支和標簽,來形成正確的最終軟件
系統集成工程師工作比較枯燥,而且系統集成總是發生在軟件發布周期的最后,壓力超級大。由于集成工程師往往也負責一部分集成測試,所以轉做測試工程師/測試經理還挺常見的。另外的職業上升途徑就像需求工程師一樣,轉做質量或者系統工程師。除此之外,轉崗并不是很容易。
集成工程師的具體工作很依賴本公司的SCM軟件,所以可能在公司A你是ClearCase大神,而轉到用PTC Integrity的公司B你就有點蒙圈了(雖然原理都差不多)。知識的通用性不是很好。但是集成工程師往往對軟件發布的流程爛熟于心,所以說轉去做質量工程師的很多。
-
成長性: 3
-
知識通用性:3
-
轉崗靈活性:3
-
工作成就感:2
-
曝光度: 2
-
工資: 3
綜合評價: 2.7 -- 這個就有點尷尬了
8. 測試工程師:要細分的話可就多了。至少可以再細分成軟件在環(SIL)測試工程師和硬件在環(HIL)測試工程師。對于底層軟件的測試,還有PIL(處理器在環)測試工程師。
HIL測試工程師的好伙伴:dSPACE Control Desk
至于測試工程師嘛....真的是個一言難盡的職位。
首先有經驗的測試工程師對整個項目而言是非常重要的。由于“V”型開發流程的存在,測試工程師甚至能通過“評價軟件需求”和“討論測試用例”兩個流程來左右軟件的設計。但是呢,通過我多年的觀察,測試工程師一般是處在軟件開發鄙視鏈的下層...
SIL 測試常用軟件 VectorCast
但是我觀察到的是,新人一旦入了測試工程師的坑并持續三年以上,基本上在這行里就和算法工程師、架構師、項目主管無緣了。我在幾個公司的幾個產品線做過,還真沒聽說以上的職位有哪位同事是長期測試出身。歡迎評論提出反例。我周圍搞測試的同事因為這個原因離職的不少。
轉崗的話,測試工程師晉升為測試團隊主管是最直接的,其他轉需求工程師、質量工程師等等也比較常見。
測試工程師的知識通用性還是很好的,找工作不難,但是工資....嗯,還行吧。
-
成長性: 3
-
知識通用性:5
-
轉崗靈活性:2
-
工作成就感:3
-
曝光度: 3
-
工資: 3
綜合評價: 3.2 -- 少年你打算一輩子獻身偉大的測試事業了么?
9. 功能安全工程師:和質量工程師、系統工程師一樣,一般是不設置在軟件部門里的,但又和軟件開發聯系非常緊密,所以我說是一位“外卡選手”。
功能安全工程師的主要職責是確保汽車軟件的開發全過程符合功能安全規范ISO26262。具體而言就是對軟件的開發設定安全目標(Safety Goal), 對功能進行險象和風險分析HA/RA (Hazard Analysis / Risk Assessment) ,以及編寫安全需求,編寫functional safety concept,最終形成功能的Safety Case (安全包?)。
除此之外,功能安全工程師還要領導失效性分析(dFMEA),故障樹分析(FTA)等等。安全工程師同時還要參與軟件需求和設計的討論。一句話,安全工程師很忙!
dFMEA工具 IQ-RM
功能安全工程師一般是由具有多年經驗的其他職位的工程師轉崗而來,畢業直接當安全工程師的也有,但機會很少。安全工程師一般是討論會上說“不”的那個人,所以小白根本鎮不住場子。新人做安全工程師的話,最開始的兩年肯定要有老師傅帶,而且會經常被人懟,不過熬過了這段時間就好了。成長性還是很高的,5分。
不同零部件的功能安全分析原理上是一樣的,而且涉及到具體功能往往有相關的算法工程師協助,所以知識的通用性很好,找工作很容易。而且現在功能安全是熱點,有3年以上工作經驗(度過了前兩年“尷尬期”)的安全工程師在市場上很吃香,不愁找不到工作。知識通用性非常高,5分。
安全工程師轉崗比較難,基本上入了安全的坑就出不去了。當然,想硬轉還是可以的,但是收入往往會下降。靈活性3分。
工作成就感嘛….主要就是在寫文檔和開會,其實成就感一般,給4分吧。
曝光度…安全工程師的曝光度那是相當的高啊,整天跟各個部門的經理、技術大拿開會,絕對是公司的明星, 5分。
工資嘛,安全工程師的工資相對還是比較高的,4分吧。
如果說需要注意的地方,那就是,小白們不要去小廠當安全工程師!安全工程師基本上沒有教材可循,都是靠企業內訓和師傅手把手教。去了小公司,內訓一團糟,流程又混亂,可能教你的師傅自己對ISO26262的理解都不到位(這種情況非常普遍)。
比如我面試的時候喜歡問安全工程師一個很基礎的問題:我們經常說"我需要一個ASIL B的信號",你能不能解釋一下到底什么是ASILB的信號?這種提法有沒有問題?還真不是每位安全工程師都答得上來。
在這種環境里待幾年,好的東西沒學到,壞毛病學一身,以后再找工作就難了。
-
成長性: 5
-
知識通用性:5
-
轉崗靈活性:3
-
工作成就感:4
-
曝光度: 5
-
工資: 4
綜合評價: 4.3 -- 真遇到了就從了吧!
最后嘛,木城想說,如果你有選擇軟件部門職位的機會,那順序應該是:
項目組長 --> 軟件架構師 --> 應用層軟件工程師 --> 驅動軟件工程師 --> 通信/診斷工程師 --> 測試工程師 --> 需求工程師 --> 系統集成工程師
不知道這個排名跟你心中的排名一樣嗎?
- 上一篇:別做線束工程師了,行嗎?
- 下一篇:車身防腐技術探討