隨著軟體定義汽車的持續走熱，各OEM車企開始建立自己的研發創新中心，關注在軟體，人工智慧，等創新研發。近在眼前的案例是，上汽集團成立上汽創新開發總院。獨立研發中心的建立，從組織授權和資金上給予了充分的保障。但是，這樣做就萬事大吉了嗎？我想，答案肯定是“
No
”
之前的系列文章，我們描述了什麼是SDV，澄清了SDV的歷史淵源以及對SDV的一些誤解，並提出了軟體驅動汽車的概念 （如何正確理解SDV，感興趣的小夥伴可以參閱公眾號文章 –正確理解軟體定義汽車）
今天，我們重點談談目前汽車行業面臨的痛點問題，如何進一步解決，讓軟體真正發揮其巨大潛能。
圖源：網際網路
透過對不同的汽車軟體開發者的訪談，以及軟體開發管理過程中的經驗教訓，@愛索諮詢認為，除去組織架構的獨立性之外，汽車軟體的轉型，目前還存在幾大方面的痛點亟待解決：
1、文化思想層面的衝突
2、人員技能的轉型
3、內部流程制度的升級
4、成本管理的轉變
1。
文化思想層面衝突
一百多年的汽車工業史，將汽車打造成了高度模組化的整合。汽車結構與機械工程師，窮盡力量確保車內不同的零部件做到最大程度解耦，保持其獨立性。但是，“成也蕭何，敗亦蕭何”，高度模組化為並行工程及外包奠定了厚實的基礎，但也導致了OEM主機廠更多關注在產品定義，造型設計，產品組裝整合和品牌宣傳上。而大量的工程、開發和製造工作，都交給了供應商來做。
但是，當大量的零部件及軟體產品是來自內部開發團隊時，傳統的工作思維將面臨諸多新的挑戰：
“甲方爸爸思維”與生態管理思維的轉換
在多年的供應商管理過程中形成的“甲方思維”又將如何適應新的情況呢？隨著軟體在整車的比重和重要性的擴大，傳統的客戶供應商關係將會演變為生態合作伙伴（如車聯網的各種生態公司），軟體平臺供應商（如自動駕駛平臺提供商），等等。這些轉變，對傳統的供應鏈體系都將帶來很大的衝擊，需要思維上的轉變。發生在2021年的汽車晶片危機，現在還在延續的，而這，就是對傳統的供應商管理體系考驗的試金石。其次，隨著OEM主機廠內部研發的建立和自主研發的起步，傳統的，管理供應商的方法將很難套用到內部團隊管理上。“甲方爸爸”的管理思維會加劇內部的衝突。需要對外、對內兩種不同的管理方式和理念，而這需要時間來磨合並消化。
下圖1展示了未來智慧車的生態場景。面向未來的智慧駕駛，更多的網際網路內容提供商（ISP）會成為汽車企業的重要生態合作伙伴，因為他們同時面對C端使用者（手機或PC端），又面對車廠（車端），所以，既不是傳統的供應商，又不是完全鬆散的“路人甲”。對於生態合作伙伴的管理，需要新的創新思維與方法。
圖1
“零部件管理”的思維與系統和功能導向的場景的解決方案思維轉換
與硬體相比較，軟體是無形的，抽象的。在傳統的零部件開發中，軟體是嵌入到硬體實體裡而不可見的，OEM主機廠更多關注的是零部件如何與整車適配在一起。而各個零部件的開發是獨立的，相互之間的介面協調更多的是透過基於控制訊號的整車物理通訊網路實現。
與之相對應的是，系統與軟體的開發，則是從客戶需求的功能場景出發。下圖2展示了典型的V2X的應用場景，需要各個ECU零部件相互協調，透過SOA的架構，形成有機整體。所以，客戶場景與市場的需求，需要的是跨場景的解決方案，更多的生態夥伴的參與。從基礎網路設施提供商，城市大腦方案商，基礎公共實施方案商到雲端平臺服務商，生態內容提供商，都考驗著汽車企業的方案設計與整合能力。
圖2 圖源：資訊通訊網
“硬體開發管理”與“軟體開發管理”的思維轉換
零部件的管理，是透過嚴苛的質量閥門的管理，供應商交付的零部件產品（軟體+硬體）將會被組裝到整車上，其生產過程，版本和釋出是嚴格計劃管控的。但軟體產品卻可以做到“柔性生產”。每天甚至每小時“生產”，隨時隨地釋出，更新替代。版本和功能的多樣性，硬體的依賴關係，等，都帶來與零部件開發管理不一樣的技能和思維挑戰（圖3）。
硬體產品開發過程中，很多依賴是無法調和的，例如，如果晶片沒有，開發工程師就無法完成電路板的焊接。但是，對於“柔性”的軟體，很多依賴卻可以找到不同的變通方法，未必是“Hard Dependency”。這需要管理層的敏捷性（Agility）以及經驗的積累，團隊的精誠合作。
圖3
“硬體產品管理”與“軟體產品管理”的思維轉換
硬體產品的“剛性”與軟體產品的“柔性”，決定了二者存在不同的產品策略。未來趨勢的判斷，隨著技術大鱷的參與，硬體會逐步標準化，通用化；而軟體的柔性卻會因主機廠的不同，客戶及市場的需求不同，展現了其多樣性，成為未來競爭的戰略要地。但正是這種柔性，也必將給OEM主機廠的各個職能系統，如生產製造系統，財務系統，採購系統，質量管理系統，技術中心，甚至人力資源部門帶來思維的衝擊與變革。這裡簡單摘取兩點進行描述。
從產品的可靠性來看，硬體產品通常存在“浴盆曲線”（見圖4），但作為軟體產品，卻是不同的可靠性曲線。隨著軟體產品的獨立釋出與演進，軟、硬體產品的質量管理將出現不同的方向和手段。
圖4
硬體產品的生命週期與軟體產品呈現不同的形態 – 硬體產品一旦裝配，將伴隨著車輛10~15年而不可更改。如有問題，只能是“召回”，無論是物理召回或返回4S店維修。但軟體產品卻是“釋出”和“更新”。現代網際網路的ICT技術，支援了遠端OTA。在整輛車的生命週期內，將會出現多輪新功能的迭代（圖5）。
軟硬體的解耦，形成獨立的產品路線圖（Roadmap）；而獨立演進，導致產品生命週期的不同，演化為不同的思路：硬體產品的標準化，通用；軟體產品的多樣化。這必將產生新的問題，如軟硬體相容性的問題，後向相容等，這都是對傳統零部件產品管理的思維挑戰。而這點，也同樣衝擊著OEM主機廠的生產製造系統 – 是要求軟體功能面面俱到還是“最小可靠”軟體？OEM主機廠的財務系統，如何更好地定義及使用軟體資本？
圖5
“硬體成本”的管理思維與全生命週期成本的思維轉換
傳統上，OEM主機廠更關注的是零部件的成本（Per Unit Cost），軟體開發成本更多地是分攤到零部件上。
當面對軟體供應商提供的軟體產品，Unit Cost又將如何定價，又如何轉化為可盈利的軟體商業模式呢？同樣，如果是內部開發的軟體產品，開發成本如何攤銷？軟體資本如何合理配置？因為軟體是“柔性”的，當管理不善，軟體的開發成本將大大超過了零部件硬體成本的節省。
BMW公司的Christian Salzmann曾經提供過一組資料：對於每年需求量為500K的一款ECU，如果每年降低硬體成本20Euro每件，在7年的生產週期內，共計可以節省70MEuro。但是，如果軟體開發沒有做到更好的重用，卻會浪費額外的100MEuro。
圖6
另外，“開源節流”，傳統的硬體成本的管理模式關注的是“節流”。但是，作為前車之鑑的ICT行業，如摩托羅拉，諾基亞，蘋果公司，汽車界的“鯰魚”（見上圖6），特斯拉，他們的軟體銷售卻打開了一扇“開源”的窗戶，透過硬體的預留，雖然短期內硬體成本上升了，但是，透過軟體的OTA迭代升級，卻創造了更大的銷售收入。這種全生命週期的成本考核，是對傳統汽車人的新的思維和管理體制上的挑戰。
2。
人才技能轉型
汽車軟體相對而言是複雜的，並且是分散式部署的。其應用領域，覆蓋了從車機娛樂軟體到安全實時控制軟體，跨度大且分散。根據其應用領域及對安全實時性要求來劃分，汽車軟體可以概括為這些領域（如圖7示例）：
車內多媒體及HMI相關的軟體開發。這部分通常對實時性要求不高，也是目前車聯網軟體的重點域
車內智慧駕艙相關的語音識別，手勢識別等AI軟體。這部分通常對實時性要求不高，更多的是基於事件的處理，部件之間的通訊是透過服務請求與反饋的形式實現
車輛底盤、動力控制，車內通訊等相關的軟體及演算法。這部分通常對實時性和安全要求高，需要非常高的可靠性。部件之間的通訊是基於訊號的控制來實現
車內與自動駕駛相關軟體，如ADAS， AVP等。這部分通常對實時性要求高，需要安全設計的考慮；同時，對算力有更高的要求，需要高效能的處理器來滿足系統功能的要求
雲端軟體及行動通訊基礎架構：這部分通常不依賴於具體的硬體，根據應用場景，對實時性要求各不相同。同時，通訊網路的開放，對資訊保安的要求日益苛刻。
圖7 圖源：瑞薩網站
透過上述簡單的軟體劃分，我們可以分析：
和整個汽車軟體關係最大的，可能就是OEM主機廠的電子電氣架構部門。但是，觀察一下各大車企技術中心、研究院的負責人，基本都是傳統底盤、發動機等領域出身。他們對智慧駕艙，自動駕駛和雲端及行動通訊，以及資訊保安的知識短板需要補足（見圖8）。
圖8圖源：QNX網站
目前，OEM主機廠基本是提供類似“Black Box”的零部件規格（SOR或RFQ），具體的實現和技術上的Know-how，基本上都掌握在供應商手裡。
如圖9所示，是來自OEM主機廠的典型VDC （Vehicle Dynamic Control）子系統功能規格書，除了這種黑盒的介面定義，軟體與硬體的實現，基本掌握在供應商手中。所以，傳統汽車產業鏈當中，對軟體瞭解最多的，應該是Tier1供應商中的汽車電子軟體部門。而智慧財產權從供應商手裡轉移到汽車OEM開發人員手裡，幾乎是不可能的。尤其是，傳統上的汽車OEM企業，基本不會為軟體開發單獨支付NRE成本 （某種意義上講，就是“白嫖”）。所以，要獲得這部分智慧財產權，更是難上加難。
圖9
受限於整個行業的發展趨勢，汽車電子軟體的主流開發大部分還侷限在微控制器（MCU）層面。最近五、六年，隨著車聯網和自動駕駛的發展，逐步轉向了基於ARM的SOC平臺，多核的晶片處理器。
目前汽車行業的從業人員，基本是利用基於AUTOSAR的自動程式碼生成工具，如Etas， Mentor Graphic， EB Tresos等，透過圖形化的介面配置應用程式，自動產生程式碼。但是，隨著自動駕駛，智慧駕艙的新功能出現，汽車對算力的要求越來越高，分層的軟體架構，作業系統和高效能SOC平臺的採用成為常態。之前的開發工具鏈開始面臨挑戰，新的工具鏈還不成熟。這對於傳統汽車行業軟體從業人員，將是新的挑戰。多年使用類似於AUTOSAR CP的工具鏈，已經讓大部分汽車軟體開發人員淪為了簡單的配置工程師，逐步喪失了底層軟體0到1的開發能力； 對底層晶片的理解更是捉襟見肘。這種挑戰將觸及靈魂。缺少必要的，成熟工具鏈來支撐程式碼的自動生成與測試，將會產生髮自內心深處的焦慮感。
圖10是節選自網際網路的一張HPC的系統架構圖。複雜的系統結構，對傳統ECU的從業人員的挑戰是巨大的。程式碼執行從傳統的單核到現在的多核，如何合理地，動態分配資源而不是之前的靜態資源分配，都對傳統汽車電子軟體開發人員帶來挑戰與技能的轉型。
圖10 圖源：網際網路
汽車電子軟體屬於嵌入式軟體開發範疇，是在專用計算機系統上進行軟體開發，一般要求開發人員具有一定的硬體基礎。主流的嵌入式平臺包含ARM、DSP、FPGA等，開發語言主要是彙編/C/C++。
相對應的是，IT與網際網路大部分的軟體開發人員，都屬於在通用計算機系統上的軟體開發，一般是在某種作業系統上，如Windows，Linux，Android，IOS等，進行應用軟體開發，主要包含電腦端，手機端，伺服器端等裝置，以X86與ARM架構為主。大部分開發人員都會使用某種高階語言，如C++，JAVA，JS，PYTHON，MySQL，等，進行特定任務的開發。
但是，對來自汽車產業外部的網際網路開發人員，雖然人數巨大（據估計，有100萬的從業人員），但如果從事汽車電子軟體的開發，卻需要了解整車架構及汽車本身的know-how（圖11）。這個限制了網際網路軟體開發人員的選擇。
ICT行業與智慧硬體的公司，以及晶片公司，也培養了大量的通訊精英（行動通訊，Wifi，Ethernet 等）和底層BSP或Firmware韌體開發團隊，他們屬於軟體團隊中最懂電子硬體的人。這部分人將是汽車電子軟體開發的最佳人選。但是，對整車架構和汽車本身的know-how的理解（圖11），也同樣限制了這部分嵌入式軟體開發人員能夠快速上手。
圖11 複雜的整車架構，需要多年的知識沉澱與積累 圖源：網際網路
AI智慧的發展，網際網路公司培養了大量的演算法人員（影象/語音/資料）。開放的網際網路精神，也培養了一批技術深厚的資訊保安團隊。而應用軟體的多樣化和成熟的C/S框架，如Restful，RCP等，也練就了一批優秀的前端和後端開發人員。因其更多的獨立於具體的硬體，或者傾向於雲端和熟悉的PC及移動端打交道，切換成本會很少。這部分人才是實現車聯網的雲端軟體，以及大資料分析的專業人才。當然，對於整車的架構，汽車產業法令、法規的瞭解以及B端市場的規律，仍然需要一定時間的磨合與歷練。
3。
管理流程升級
百年的汽車工業開發，形成自己特色的，基於質量閥門的整車開發流程。透過這種流程，把OEM主機廠和其Tier1，Tier2供應商密切地聯絡在一起，形成有機的開發整體。但是，隨著基於功能和場景的解決方案逐步發展，軟體佔據主導地位，現有的OEM開發流程卻不能很好地適應軟體系統與軟體工程，流程面臨巨大的挑戰，需要全方位的系統建設。這種流程的系統化建設，需要流程的架構與設計，它涵蓋了組織制度，角色和職責等維度（具體參閱公眾號文章：行雲流水般的流程）：
需求管理流程
傳統的開發模式是OEM主機廠負責系統和子系統的功能及介面定義。但是，很多子系統的劃分是根據物理的機械件（ECU）及介面進行了劃分，相應的負責工程師也跟隨相應的硬體耕耘多年，形成自己的專業know-how；但是，專業化的分工，形成“I”字型的知識架構。不同的零部件之間的技術壁壘逐步產生，甚至各自為政，“老死不相往來”。問題是，如圖12所示，基於場景的需求開發需要多個子系統的聯動；需要“T”字型的知識架構。如何分解需求；如何進行需求管理；分層管理；如何做到需求的重用；如何減少各功能之間的依賴，都對原有的流程產生新的挑戰。
汽車OTA功能的實現，如何管理汽車上市後的OTA功能與需求，如何連線運營，4S售後服務等功能需求，如何隨時提供雲端服務功能，都需要對原有基於零部件開發的流程進行改造。
圖12智慧汽車功能需求
架構設計與介面定義流程
汽車工業的傳統模式，軟體的know-how 基本被有實力的供應商把控，具體的軟體實現，介面定義，對OEM是不可見的。所以，如何確保不同的ECU軟體有機結合，協調實現必要的場景，相應的工作機制需要建立。
而車、管、端三位一體的未來發展方向，三者的聯動的架構設計，同樣需要合理的流程機制來保障。伴隨著SOA架構的逐步實現和車內通訊線路的乙太網化，介面的定義將逐步從基於訊號的定義或者簡單的訊息結構的定義C/S模式轉向更復雜的SOA架構與介面定義（如圖13所示）。當衝突發生，需要相應的技術仲裁流程進行合理評估。
圖13 介面定義將由簡單的C/S模式向更復雜的介面定義演進
程式碼與整合流程
汽車的造型設計形成不同的車型及零部件的Fit和Form。傳統的零部件開發模式，不同Fit的零部件的軟體程式碼各不相同。如何有效地重用程式碼；如何構建軟體架構平臺；如何將不同程式碼整合在一起，成為新的挑戰。需要新的流程來確保軟體程式碼的重用性及軟硬體的整合。
產品與專案管理流程
傳統的零部件產品與專案常常合二為一。一旦硬體最終認可，軟體將隨之凍結，直至生命週期的終結。但是，智慧車的軟體產品卻可以隨時增加新的功能，形成新的版本，透過遠端OTA進行更新。可以想象，未來同一款硬體，將會預裝不同的軟體版本，在市場上銷售。如何管理客戶車輛的軟體版本，如何管理軟體的相容性，等等，需要新的流程改造。而專案管理，如圖14所示，可能會以軟體開發管理為主，在硬體產品的生命週期內，透過專案的模式組織軟體的交付。
圖14
售後服務的流程
隨著軟體遠端診斷的開啟，以及AI及IOT技術的落地，基於資料的售後服務體系終將建立。傳統的4S服務的模式將逐步轉移到線上。如圖15所示的遠端服務體系的場景將成為常態，相應的流程體系的改造也勢在必行。多生態合作伙伴的介入，如何管理端到端的場景解決方案，提供更高的服務質量，都是OEM主機廠面臨的問題。
圖15 複雜的智慧汽車場景
開發工具鏈的挑戰
各種自動駕駛，人工智慧，軟體演算法，雲端軟體的開發訴求，將會促使新的開發工具鏈。或者傳統的工具鏈進行演化，如基於AUTOSAR CP開發的工具鏈將進一步進化為AUTOSAR AP等（見圖16）。而流程的最佳化和改造，同樣需要類似JIRA，禪道，Synopsys，RobertFramework之類的軟體開發測試驗證等工具鏈的引進。
圖16 AUTOSAR工具鏈 圖片源自CSDN
4。
成本管控方式轉變
做過汽車Tier1供應商的小夥伴，我相信都經歷過那種血淋淋的汽車零部件的商務報價過程 – “沒有最低，只有更低”。最後的後果，不管你是否相信，會是產品質量的喪失。這從一個維度，充分反映了目前傳統OEM主機廠的思維定式：一輛汽車的功能決策，更取決於零部件的價格。在過去以機械結構為主的汽車中，這個做法可以理解。但是，隨著軟體驅動汽車的發展，如前面幾篇文章所述，全生命週期的成本的權重要遠大於目前單件成本的爭奪。對比來看，在新勢力造車的蔚小理中，交付讓消費者眼前一亮的功能卻被視為更為重要的決策依據。
在零部件採購中，這種“砍到骨頭”的低價策略，會帶來負面影響。工程師們，不管是來自供應商或者OEM主機廠，會不斷地降低處理器的算力，記憶體，通訊頻寬等關鍵計算資源，從而降低硬體成本。如此一來，卻對軟體帶來根本的損害及不可預測的後果：
軟體工程師們將不得不最佳化軟體程式碼，以適應有限的計算資源
。但因為系統的複雜性，這樣的後果是，在未來的效能測試中發現各種莫名其妙的問題，導致很難查詢根本原因，從而增加了工程成本，甚至延誤了產品的上市週期。另一方面，儘管沒有找到問題的根源，迫於專案的進度，工程師們也是“拆東牆補西牆”，採用臨時方案應對專案的交付，為量產後的產品質量種下隱患，增加了售後服務的成本。
軟體工程師不得不壓縮他們的程式碼，確保其足夠的小，可以被調入有限的記憶體執行。
程式碼要足夠地精簡，確保記憶體的每一位（Bit）都能被充分利用。如此一來，任何新功能的增加將變得幾乎不可能。更有甚者，甚至缺陷的修復也將無從下手，而不得不進行硬體的召回。這些，在增加了工程師成本同時，進一步加劇了公司的售後服務成本，消減了公司的軟體銷售收入來源。
由於程式碼的過度最佳化，會導致後期的程式碼維護尤其困難。
複雜的語句，讓後期維護人員不敢有絲毫的觸碰。對程式碼的修改成為每個人心中的噩夢。
過度精簡程式碼，將會很難做到程式碼的重用及其可移植性。也無法做到功能的預埋
。如此一來，唯一的途徑是透過OTA進行從上到下的韌體和應用軟體的更新。從客戶成本的角度，浪費了客戶的時間，增加了流量成本。從業務的角度，增加了內部的運營成本及軟體工程成本。
圖17 全生命週期成本
這裡，我們並不是強調傳統的Cost Per Unit的成本管控不重要。我們強調的是全生命週期的成本概念。如圖17所示。所以，在評估零部件的單件成本時，除了零部件相關成本之外，必須考慮其帶來的專案延遲風險，產品上市視窗，工程成本，除錯成本，售後服務成本，程式碼複用以及未來新的銷售收入增長的機會成本。
消費者需求的多樣性和定製化的訴求，驅使主機廠在配置上形成不同的配置版本，產生不同的汽車Variant。以“簡單的動力系統控制的應用功能來講，會有3488中不同功能配置”（注：來自Manfred Broy）。而目前的奢華車，基本配備120個左右的ECU，簡單的“有”或“沒有”的配置，會有2120種Variants，供消費者選擇。除了市場和使用者的驅使，在整車長達10~15年的生命週期內，各種小改款，中期改款，大改款，VAVE層出不窮，同樣結構的ECU，會有不同的FIT，FORM，也可能預裝了不同的軟體版本。如此眾多的Variant，需要巨大的驗證與確認工作，必將產生龐大的汽車工程成本。同樣，龐大的汽車Variant，也對售後服務的備件，服務技能和召回預算形成巨大的壓力 。
汽車行業的“賴特定律”（注：萊特定律由美國航空工程師西奧多·賴特在1936年提出，他將製造效率和製造經驗聯絡起來，其核心是每生產一定單位的產品，其製造成本將下降恆定的百分比）指出，“單個型號的汽車產量每累計增加一倍，成本的價格就會下降15%”。這終將會驅動硬體的標準化，降低汽車的Variants，從而降低汽車工程成本；功能的差異化實現，則更多地透過軟體來競爭。
圖18 某品牌汽車OTA升級新聞
然而汽車軟體帶來的成本增加，將越來越顯現。如何管控軟體的劣質質量成本，將成為擺在每一位汽車從業人員面前的一道關卡。圖18是關於某品牌汽車的OTA升級的一則新聞（德國《汽車與體育》（Auto Motor und Sport） 報道），12小時的升級過程，7。5小時的軟體安裝過程。按4G網速計算，升級包高達30G，單車流量費將高達三位數。更令人大跌眼鏡的是，電池電量居然被耗光，這讓消費者情何以堪？
汽車工程成本的另一個維度，是汽車軟體的Variant。傳統的ECU零部件，在整車的生命週期內，會有不同的FITs，Form等。但是，不同外觀尺寸的ECU與ECU之間的軟體差異可能不超過10%。不幸的是，因為軟體的不重用性以及單位硬體成本的管控理念、採購理念，導致軟體很難從一個ECU很快地移植到另一個ECU。這使得大部分軟體不得不被重寫（據德國汽車工業提供的資料，大部分軟體的改動其實只有10%的差異性。）。隨著車子智慧化的發展，底層硬體的通用化，軟體重用的趨勢是必然。如此一來，軟體產品的觀念（見圖19示例圖）急需在整車廠建立並實踐。
圖19 軟體產品概念示意圖
5。
寫在最後
SDV，軟體驅動汽車，毋庸置疑，已經是實實在地擺在每一個組織，每一位汽車從業人員面前的課題。儘管汽車軟體，相對硬體而言，體量仍然渺小，其在成長的道路上需要“水”，“土壤”和“陽光”，需要企業管理者和每一個汽車從業人員的愛護和澆灌。但是，面對這個汽車產業這個百年未有之大變局，軟體必將撬動整個汽車的產業鏈，在汽車生命週期的各個環節，如圖20所示，產生新的價值，驅動創新與再造。
圖20 汽車生命週期生態鏈
在這個過程中，覺醒的OEM開始與外部公司合作，例如零束汽車軟體與愛索管理諮詢的雲端釋出DevOPS改造；極氪汽車的整車流程最佳化、再造，軟體稽核等。這些都是順應軟體驅動汽車之大變局，透過廣泛的生態連線，構建健康的軟體生態鏈；另一方面，也正反映了企業開始正視面臨的問題，透過價值洞察，積極推進組織變革，思維變革，技術know-how， 人才儲備以及流程制度的建設。
只有這樣，才能構建軟硬融合的產業生態，讓智慧汽車，乃至自動駕駛技術越走越遠。
作者介紹：
宋濤
，原ICT行業20年的研發高管，貝爾實驗室資料科學家，六西格瑪黑帶大師，現為愛索諮詢的CTO兼首席諮詢顧問。
歡迎加入智慧交通技術群！
