女人自慰AV免费观看内涵网,日韩国产剧情在线观看网址,神马电影网特片网,最新一级电影欧美,在线观看亚洲欧美日韩,黄色视频在线播放免费观看,ABO涨奶期羡澄,第一导航fulione,美女主播操b

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

汽車軟件定義危機是如何釀成的?

佐思汽車研究 ? 來源:佐思汽車研究 ? 作者:佐思汽車研究 ? 2020-12-04 16:01 ? 次閱讀

引言:

又是一個思緒亂飛的夜晚,花了7個小時碼出了下面這些內容,今天不講技術,主要談談之前的一些經驗教訓供大家參考。 大家經常會聽到車廠要招幾千上萬人的軟件團隊,先不看具體的內容,聽起來好像軟件就是一個勞動密集型的產業,只要堆人就行了。殊不知,這只是在從一個坑跳進另外一個更深的坑,新勢力們已經構建起了部分的軟件能力,傳統的車廠正在努力追趕,這個行業一片欣欣向榮的景象,但先行者的很多的經驗教訓是值得大家好好反思的。前段時間,大家都在談傳統車廠的軟件危機,這些都是不具備能力所產生的危機,等到大家都有軟件團隊了,更多的危機還在醞釀當中,汽車技術的復雜性,進一步讓這些危機更加明顯。

1

軟件危機

軟件危機是軟件工程領域的一個說法,說的就是軟件工程中所表現出的各種問題,主要體現為以下幾點。

成本日益增長

開發進度難以控制

軟件質量差

軟件維護困難

看起來比較抽象,我舉幾個具體的例子,大家自檢一下:

為什么別人家的軟件一個月可以更新好幾次,而自家半年過去了,非常努力的敏捷開發而一個版本也發不出來?

為什么每個功能域都覺得自己沒問題了,集成到一起就問題層出不窮?

為什么修好了一個 bug,又冒出來幾個其他 bug?

為什么開發告訴我這個功能技術方案太復雜,這期來不及,以后再做,然而以后還是來不及?

為什么一些功能邏輯只有到了實車上,才發現原先的設計邏輯有問題?

為什么第一款車已經做過一遍了,這款新車就適配一下,還需要這么長時間?

為什么規劃了個新架構,到最后只能做點小優化?

為什么開發告訴我,自己要維護十幾套代碼基線,功能不都差不多嗎?

為什么......

2

軟件與 EE 的沖突

無法掌控電子架構,軟件架構就是空中樓閣,軟件部門經常會和 EE 打交道,特別是在新的軟件化浪潮下,雙方經常會起沖突。其實靜下心來分析,這種沖突是雙方認知不同造成的必然結果。 傳統的EE一般來自于電氣電氣自動化、汽車等相關專業,主要有以下幾個重要職責:

功能定義及分配

網絡拓撲及信號分析

信號及接口定義

電源分配

線束設計

在傳統的離散架構下,其工作以信號為基礎,圍繞網絡與零部件展開,車上的很多功能往往需要多個 ECU 相互配合,定義功能邏輯、信號交互、管理 ECU 零部件開發是日常的工作重心。 在傳統的架構下,其工作模式其實是至下而上的,所有的功能性 ECU 都是產業鏈上有的,組合起來形成各種產品功能。 而在新架構下,工作模式需要至上而下,底層 ECU 提供的都是原子功能,功能邏輯都是在中央計算單元中實現。所以原本的功能定義和劃分職責,現在變成了功能拆解、原子服務定義。

3

功能域相互扯皮

在傳統的架構下,如果組建開發團隊,很自然的就會按照零部件或者功能域去劃分,比如智駕、座艙、網關、BCM、VCU 等,一旦這種組織架構形成,想要推行新的技術架構,就會產生非常大的阻力。 組織架構往往是由分工邊界決定的,一旦組織架構確定,就會形成一個利益團體,有句話叫撼動利益,比撼動靈魂還難。 舉個例子,在中央計算架構下,中央網關退化為多個區域網關,之前中央網關開發的人去干嘛?把 BCM 和 VCU 的業務功能放到中央計算單元的車控單元之后,這些業務由誰來開發?新的架構要取消這兩個 ECU,原來的開發部門會同意? 從這個維度來看,你就知道為什么在傳統車廠內部搞這種底層的數字化架構基本沒戲,這不是一個單純的技術問題。另外,如果出去單獨成立新軟件公司,如果不能決定 EE 架構的,基本也沒戲!

4

車型項目與數字架構平臺化

所有的公司剛開始做的時候,毫無疑問最關注還是產品功能,不管怎樣先把產品弄出來再說,所有的資源都是圍繞著車型的項目在推動。 等到一個車型項目做完,下一個車型項目又開始了,一旦這個過程啟動,任何有點技術風險嘗試都會被扼殺在搖籃當中,所以永遠只能做漸進式的改變,這就導致,會衍生出很多個軟件版本。以后每增加一款車型,就要多維護一條產品線。 在靠硬件差異化拼天下的時代,傳統的巨頭都是車型平臺化設計的高手。一個車型平臺,需要投入上百億的資金進行研發,一家大型的車企,可能同時擁有幾十款車型,如果每款車的架構都是不一樣的,全部都重新開發,這個成本誰也無法承受。

車型平臺

我想在他們內部也不會有人質疑,為什么要花這么大的成本去開發這樣一個車型平臺,因為經過了時間的檢驗,采用平臺化設計為他們帶來了很多好處:

縮減開發成本

縮減產品開發周期

為不同車型的硬件差異化提供了基礎

5

傳統車廠的歷史包袱

在傳統的汽車上,一個零部件隨著整車出廠之后,軟件一般不會再進行升級,但在OTA的大背景下,車的生命周期被延長,軟件在一定的周期內會進行不斷的迭代,如果沒有平臺化的軟件作為支持,產品功能的迭代會產生巨大的工作量,而且迭代速度會非常緩慢。 按照傳統車廠的節奏,會頻繁的推出新的車型,如果沒有平臺化的軟件作為支撐,光是車型適配的工作就會產生大量的開發成本,更不要談后續的OTA升級,以后每增加一款車型,就要多維護一條產品線,到了最后,可能不得不去放棄一些銷量較低的車型的軟件迭代工作,這對于購買那些車的用戶來講公平嗎。 在傳統的印象中,軟件為什么毛利潤那么高?很重要的一個原因是軟件的可復制性,在復制部署的過程中,其邊際成本趨近于零。而軟件可復制部署的前提是軟硬件的平臺化。要在一輛未經良好設計的汽車上去迭代軟件,后期本身就會演變成一個災難。 國內車聯網的先行者第一款車發布的時候整個人員規模也就300人左右,后續隨著體系內的車型不斷變多,導致的適配工作呈現倍數放大,人員規模很快膨脹到近千人,主要的資源力量都被吸引到了車型適配當中去,無形之中也影響到了主線產品的開發節奏,即使是把這部分工作交給外包去做,依然也要付出巨大的人工成本。 為什么會產生如此大的適配工作量呢?可以先給大家介紹一下,軟件適配車型具體的工作范圍。 車載軟件系統,開發出來之后,只要芯片平臺不變,操作系統不變,按道理來講是不需要什么適配工作的。但是但由于傳統車廠的一些歷史遺留問題,以及產品設計理念的問題,會產生以下三類問題。

車型平臺、車型信號不同,導致信號的適配
新的車型,如果是基于同一個車型平臺開發出來,其一般只是信號的值,或者信號的個數發生了變化,但是如果兩款車基于完全不同的車型開發出來,基本上信號共用的部分就很少,同樣是控制某個功能,信號的名稱可能完全不一樣,并且一個車型上發一個信號能完成的功能,到了另外一個車型上,可能需要多個信號組合才能完成。這會導致,像網關、TBOX、域控MCU、域控MPU的車輛信號處理的中間件、HMI控制邏輯等模塊需要進行軟件變更。此類功能,是車載軟件開發中聯調工作最大的部分,并且還必須是在早期就具備的功能,比如PPV階段,就要求此類功能ready,而其他大部分功能都可以放到SOP階段,和其他零部件交互的功能,都是聯調中最麻煩的,特別是在早期階段,工程師需要跑各種現場分析解決問題。

屏幕適配
咱們國內的整車的產品人員對智能化的理解是不是太膚淺了,喜歡定義各種規格的屏幕尺寸,多搞幾塊屏幕,沒事兒還橫屏改豎屏,豎屏改橫屏,似乎誰的屏幕多、屏幕大就更智能似的。殊不知,多一塊屏幕或者是改變了屏幕的橫豎關系,就要重新定義交互方式,而改變屏幕分辨率,也會導致UI布局上的調整, 這些改變會導致軟件上巨大的工作量。

車型特殊硬件,增加新的軟件模塊
傳統車廠的車型產品中,喜歡弄一些差異化的硬件,而這些功能往往需要增加新的軟件模塊才能運行,此類功能倒是比較好處理,因為新增的模塊總比改已有的模塊要方便,新增只影響一個車型,而改已有的模塊會影響其他所有車型。

芯片平臺不同

以上的這些因素都會導致軟件的變更,而軟件的變更也分為幾個層次,軟件工程中一般會使用git等工具來管理代碼,在軟件開發過程中,幾十上百個軟件工程師會共同完成同一個項目,這里面很重要的概念就是“主線”與“分支”,如果多個車型項目的代碼能夠復用同一“主線”,意味者他們的代碼是同一套,工作量會小很多,但是如果某個車型的軟件變更,導致他們無法再用同一套,在軟件上就會產生一個新的分支,就像大家平時多個人要共同編輯某個文檔,一旦大家的修改產生了分叉,就必須同時維護多個版本。

從軟件工程的角度來講,軟件開發的一般分為,需求分析、領域建模、架構/概要/詳細設計、開發/單元測試、綜合測試、編譯集成、發布等幾個階段。每增加一個分支,就會導致從開發開始所有流程工作量的增加。 從軟件的角度來看,采用一些技術上的設計,可以復用已有的模塊分為以下幾個層次:

共用同一分支,一次編譯,生成一個軟件包,能夠在所有車型上運行(就像app能夠在所有Android手機上運行)。

共用同一分支,多次編譯,生成多個軟件包,能夠在不用車型上運行。

部分模塊共用同一分支,多次編譯,生成多個軟件包,能夠在不用車型上運行。

采用不同分支,多次編譯,生成多個軟件包,能夠在不用車型上運行。

有人也許會問,為啥要搞這么復雜,每個車型都采用不同代碼,不是更好管理嗎?傳統車廠包給Tier1做的時候,也的確是這樣,因為那個時代,軟件和硬件一樣,都是一錘子的買賣,不需要后續還進行什么升級。今天我們談論軟件定義汽車的前提就是,要通過OTA不斷的為車升級新的功能。如果都采用不同的代碼版本,意味著軟件開發團隊的規模是和車型的數量成正比的,越往后面迭代,已有的車型都會變成歷史的包袱。 很多時候,大家在開始做項目的時候,最關注的還是產品功能的實現度,很少關心軟件的架構設計和拓展性,積累到一定的階段,又不敢輕易的進行重構,而后產生惡性循環,導致開發資源的大量浪費,功能大家都能做,但工程能力的高低往往體現在這些看不見的地方。 構建一套基礎的軟硬件平臺,通過良好的架構設計,在標準的軟硬件基礎設施上,開發出完備的工具鏈,以支持車型功能的快速開發與快速迭代,是軟件定義汽車的基礎。

6

總結

寫了比較多的內容,思路也比較發散,總結下來有以下幾點建議:

在構建新的數字化架構的過程中,如果牽頭人不是像馬斯克這種有技術決斷力的領導,最好就構建一個強有力的架構團隊,從技術層面總領全局,否則靠功能域自己相互協調,只能做點優化,改變不了基礎架構。

構建的架構團隊必須包含定義計算通信架構的職責,靠 EE 和軟件架構各自為戰,做出來的也是個漸進產品。

各功能域的職責在新的技術架構下是會發生變化的,不要試圖在原有的組織架構下搞出新的技術架構。

產品線開發和平臺開發要分開,否則就會面臨邊開飛機邊換引擎的慘痛局面,開發資源永遠被現有項目所圍困。

新平臺的開發是一個 EE+硬件+軟件的綜合體,如果總想拿正式車型項目去推動,會讓項目面臨很多不可控風險。新平臺的正向研發過程中面臨很多技術決斷,建議成立一只獨立團隊開展前期研究工作。在一定階段導入正式量產項目。本質是把 R&D 中的 Research 與 Development 分開,并且將 R 前置。

原文標題:軟件定義汽車 (第九集) : 危機是如何釀成的

文章出處:【微信公眾號:佐思汽車研究】歡迎添加關注!文章轉載請注明出處。

責任編輯:haq

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • 電動汽車
    +關注

    關注

    156

    文章

    12375

    瀏覽量

    234154
  • 軟件
    +關注

    關注

    69

    文章

    5121

    瀏覽量

    88962

原文標題:軟件定義汽車 (第九集) : 危機是如何釀成的

文章出處:【微信號:zuosiqiche,微信公眾號:佐思汽車研究】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦
    熱點推薦

    軟件定義汽車時代為什么中間件受青睞

    在“軟件定義汽車”時代,隨著汽車軟件功能漸趨多樣化,硬件和軟件組件之間的通信和交互開始變得復雜。
    的頭像 發表于 06-09 11:14 ?178次閱讀

    軟件定義汽車電源管理設計:NXP的PMIC選型攻略解析

    汽車行業正在穩步邁向軟件定義汽車 (SDV)。制造商和駕駛員對各種技術的互聯性和可升級性充滿期待,特別是通過無線 (OTA) 軟件更新,實現
    的頭像 發表于 06-06 09:50 ?678次閱讀
    <b class='flag-5'>軟件</b><b class='flag-5'>定義</b><b class='flag-5'>汽車</b>電源管理設計:NXP的PMIC選型攻略解析

    軟件定義汽車如何改變未來出行

    汽車行業正加速駛入一個由軟件定義汽車 (SDV) 主導的新時代。這些車輛不再只是交通工具,而是一個能夠持續進化的技術平臺,依托不斷更新的軟件
    的頭像 發表于 05-20 09:52 ?213次閱讀

    軟件定義汽車將如何變革汽車行業

    在技術快速發展的背景下,軟件定義汽車(SDV)正迅速崛起,成為未來出行的焦點。它將如何變革汽車行業,并帶來哪些前所未有的機遇呢?讓我們一起探索這個激動人心的領域!
    的頭像 發表于 05-16 10:00 ?193次閱讀

    軟件定義汽車時代,Elektrobit談虛擬開發到量產落地的效率躍升

    電子發燒友網報道(文 / 吳子鵬)軟件定義汽車(Software-Defined Vehicle, SDV)正掀起汽車產業的革命性變革,推動行業從機械硬件主導邁向
    的頭像 發表于 05-12 09:25 ?5125次閱讀
    <b class='flag-5'>軟件</b><b class='flag-5'>定義</b><b class='flag-5'>汽車</b>時代,Elektrobit談虛擬開發到量產落地的效率躍升

    解鎖未來汽車電子技術:軟件定義車輛與區域架構深度解析

    解鎖未來汽車電子技術:軟件定義車輛與區域架構深度解析 ——立即下載白皮書,搶占智能汽車發展先機 *附件:解鎖未來汽車電子技術:
    的頭像 發表于 04-27 11:58 ?464次閱讀

    軟件定義時代:CAN SIC如何升級電動汽車的通信網絡?

    本文探討了軟件定義汽車(SDV)對汽車行業的影響,以及實現這一目標的硬件和軟件可升級的汽車。其中
    的頭像 發表于 04-22 11:49 ?201次閱讀
    <b class='flag-5'>軟件</b><b class='flag-5'>定義</b>時代:CAN SIC如何升級電動<b class='flag-5'>汽車</b>的通信網絡?

    BlackBerry QNX:軟件定義汽車的現狀及發展方向

    放眼全球,“軟件定義汽車”的進展已到達轉折點。 回望五年前,整個汽車行業認識到,軟件對于新一代汽車
    的頭像 發表于 02-20 14:43 ?1049次閱讀

    QNX攜手微軟加速軟件定義汽車發展

    BlackBerry有限公司(紐約證券交易所代碼:BB;多倫多證券交易所代碼:BB)旗下的QNX部門今日宣布與微軟達成合作,雙方將通過云平臺幫助汽車制造商更高效地開發、測試和優化軟件,加速軟件
    的頭像 發表于 01-07 16:18 ?498次閱讀

    軟件定義汽車是智能駕駛發展的關鍵推動力?

    編者語: 「智駕最前沿」微信公眾號后臺回復: C-0604 ,獲取本文參考報告:《軟件定義汽車,RoboTaxi前瞻》pdf下載方式。 RoboTaxi(自動駕駛出租車)作為高級別自動駕駛技術的主要
    的頭像 發表于 12-23 10:48 ?608次閱讀
    <b class='flag-5'>軟件</b><b class='flag-5'>定義</b><b class='flag-5'>汽車</b>是智能駕駛發展的關鍵推動力?

    FPT和電裝簽署諒解備忘錄,加速軟件定義汽車的創新步伐

    FPT與電裝簽署MOU,攜手推進軟件定義汽車發展,合作內容包括共建離岸開發中心。
    的頭像 發表于 12-18 12:02 ?572次閱讀
    FPT和電裝簽署諒解備忘錄,加速<b class='flag-5'>軟件</b><b class='flag-5'>定義</b><b class='flag-5'>汽車</b>的創新步伐

    智能駕駛加速軟件定義汽車步伐?

    以往的硬件制造逐步向軟件賦能轉變。隨著“軟件定義汽車”(Software Defined Vehicle, SDV)的概念深入人心,汽車制造
    的頭像 發表于 11-25 11:01 ?668次閱讀
    智能駕駛加速<b class='flag-5'>軟件</b><b class='flag-5'>定義</b><b class='flag-5'>汽車</b>步伐?

    軟件定義汽車引發的產品開發大變革

    軟件定義汽車的設計初衷是在汽車整個生命周期內通過無線更新不斷增強。基于云的虛擬化新技術允許開發始于芯片量產之前,并延續到汽車上路之后。
    的頭像 發表于 11-01 11:44 ?827次閱讀

    軟件定義汽車的大背景下,MathWorks如何更好地賦能汽車設計

    電子發燒友網報道(文/吳子鵬)未來的汽車將更多地依賴于以AI(人工智能)為核心的軟件技術,而非傳統的機械性能或物理配置,這便是軟件定義汽車
    的頭像 發表于 09-18 00:03 ?4034次閱讀
    在<b class='flag-5'>軟件</b><b class='flag-5'>定義</b><b class='flag-5'>汽車</b>的大背景下,MathWorks如何更好地賦能<b class='flag-5'>汽車</b>設計

    使用MATLAB、Simulink和Polyspace加速軟件定義汽車開發

    開發軟件定義汽車 (SDV) 時,開發團隊必須具備新的能力,例如進行連續的軟件發布,減少軟件更改的交付周期以及盡可能減少部署失敗。同時,平臺
    的頭像 發表于 09-05 09:57 ?984次閱讀
    使用MATLAB、Simulink和Polyspace加速<b class='flag-5'>軟件</b><b class='flag-5'>定義</b><b class='flag-5'>汽車</b>開發