汽車架構越來越多地由軟體驅動，這一轉變簡化了升級，在汽車中新增新的功能變得更加容易。
所有這些都得益於汽車功能和特性的日益數字化，從機械設計轉向電氣設計，且越來越多地從模擬資料轉向數字資料。這使車廠能夠在出售車輛的數年後仍可以增加或追加銷售功能，如自動駕駛功能。它還使車廠能夠在車輛的生命週期內，隨著安全要求和連線協議的變化而隨時更新車輛。
但要使汽車真正實現軟體定義，整個汽車平臺的硬體和架構必須被重新設計。而目前的車輛並不是這樣製造的。
西門子數字工業軟體公司自動駕駛和ADAS SoC高階總監David Fritz說：“這意味著大多數OEM都選擇了一箇中央計算架構。這可以是異構或同構的。這部分並不重要，只要是一個架構（一個軟體架構，一個硬體架構），因為這允許OEM說，‘我要讓客戶下載一個新的應用，可以完全改變他們的駕駛體驗’。”
其他人指出了類似的趨勢。Rambus的研究員和傑出的發明家Steven Woo說：“你已經有了這個移動的硬體，應該是這樣的，你可以把它定製為你想要的外觀和感覺，類似於流媒體服務等的配置檔案。為什麼不應該是這樣呢？”
Woo說：“在CES上，你可以看到很多類似的未來概念汽車。有一輛車的內外都覆蓋著LED。不同的司機可以擁有相當於遊戲中的頭像或面板。你可以根據你的心情定製它，你可能有一個特定的預設。從軟體定義的角度來看，應該是這樣的，根據需要和一天中的時間和你的心情，或者你在那一刻的任何需求，可以定製內部的外觀，以及你正在播放的音樂型別、影片型別，甚至那些吸引你注意的東西。這些都是可能會發生的。”
Fritz說，德國的一位高管給他看了一輛車，說：“這是我們的願景。當他啟動車輛時，裡面所有的燈都亮了，你會聽到，像‘Scotty向Kirk船長彙報’，就像星際迷航一樣。他說，‘想象一下人們下載這種體驗。也許我不想在星際迷航中出現，也許我想成為神奇女俠，或者想有一個復仇者聯盟的體驗。我希望能夠選擇我的體驗，並讓車輛自己適應。車輛面板的支援將是一個差異化的因素。”
要做到這一點，需要對整個車輛系統進行分層處理。Ansys半導體業務部產品營銷總監Marc Swinnen說：“這包括硬體堆疊，也就是汽車和引擎，等等。在這之上是控制鐳射雷達、雷達、引擎的晶片堆，這些晶片驅動硬體。然後，在這之上是一個作業系統，今天許多OEM正在建立這個系統，以管理車輛中的所有操作。此外，還有一個應用堆疊，上面有一個軟體堆疊，汽車將透過這些應用進行互動。因此，這是一個更傳統的電子系統模型，而汽車只是該堆疊中的硬體層。”
界定軟體定義的架構
軟體定義的汽車是一個不錯的標籤，但它到底意味著什麼？Synopsys嵌入式軟體解決方案和系統高階總監Marc Serughetti說：“最終，我們必須回到原點，看看它到底意味著什麼，然後它如何影響系統，以及它存在的理由。歸根結底，這都是關於OEM想要在汽車中實現的功能。如今，電動車驅動著汽車市場。它受到ADAS的驅動，正朝著自動駕駛的方向發展。我們知道它是由網聯、共享出行和類似的東西驅動的。OEM面臨的挑戰是，既然這些都是消費者想要的東西，如何開始交付一個能夠實現所有這些功能的產品？在過去，汽車生態系統的發展方式是，新功能要加入一個新的硬體來解決這個功能。但新趨勢不允許這種方法，它不再起作用了，因為這些功能不是獨立工作的。它們是相互聯絡的。另一方面，希望擁有先進功能的消費者想要在汽車上也實現像手機那樣的功能升級。”
這是OEM和Tier 1背後的一個巨大推動力，現在他們在質疑所有這些對他們意味著什麼，他們將如何在未來脫穎而出，以及如何實現他們的目標。
Serughetti說：“實現這一目標的方式是透過在軟體中實現這些功能。汽車生態系統中的很多公司都在談論’軟體優先‘戰略，以及這對產品和交付的影響。把它帶到硬體上，會有一些影響。首先，你不能是和以前一樣的架構，你不能是還像以前那樣ECU分散式的架構。你需要改變汽車的電子架構，這就是為什麼人們在談論中央計算機/zonal閘道器域控制器之類的東西。在這些領域中正在發生徹底的變革，是為了支援軟體。”
第二個難題是需要什麼型別的晶片。“你將需要算力非常強大的晶片，還需要AI支援。第三是軟體。現在，因為有這麼多的計算元素，而且你想利用算力，例如，如果正在考慮zonal架構，你說，’我有不同的zonal控制器，而且我想做一個計算。為什麼不能使用其中一個zonal架構提供的算力，如果沒有足夠的算力，為什麼我不能使用車輛中另一部分的算力？整個軟體驅動的方法也在影響著電子系統，這意味著硬體和軟體一起。而這也有隱含意義。從軟體的角度來看，這在作業系統方面意味著什麼？我們開始看到OEM認識到需要有自己的作業系統。而且我們說的不只是RTOS。他們談論的是完整的基礎設施。”
功能和安全問題
Cadence解決方案和生態系統高階團隊總監Frank Schirrmeister表示，這引起了一堆新問題。“軟體能用嗎？它夠安全嗎？安全性、舒適性和便利性正在真正推動著這些東西，汽車似乎正在成為有生命的物體。車輛正在成為一個不斷髮展的硬體/軟體平臺。縱觀整個行業，車輛基本上是一個IoT裝置，成為消費者的樞紐。所有這一切的基礎是軟體和硬體解耦的優雅，同時有軟體改進並行執行，幾乎像一個敏捷的開發環境。”
雖然這些向軟體定義汽車的轉變包括下一代車輛架構的樣子，但它們也決定了車輛功能的走向。
Arm汽車和IoT業務線的汽車合作總監Robert Day指出：“我們現在正在從分散式的方法轉變，在這種方法中，汽車中的每個功能都有自己的ECU，而且它們分散在車輛周圍，微控制器多到你不知道該如何是好，這開始轉變為一種叫做domain架構的東西，汽車中的每個域都有自己的計算，然後有自己的ECU與之連線。一個用於ADAS，一個用於車內娛樂，等等。這意味著更多的整合，但這是圍繞功能的整合。每個功能都有自己的微處理器和一堆微控制器。這就是我們今天在這個domain控制器世界裡的情況。”
圖1： 軟體定義的車輛中不斷上升的複雜性（資料來源：Arm）
下一個轉變將是進入更多的zonal，每個zone將有自己的zonal控制器。因此，汽車的每個角落將有不同的感測器，它們將被輸入到一個zonal控制器。該zonal控制器將把其zonal的資訊傳遞給一個大的中央計算機。
Day說：“我們已經從domain變成了zonal，每個zonal與一個大的計算機連線，這個大的計算元素（也就是通常被稱為‘車輪上的資料中心’）然後將對來自不同zonal的資訊做任何必要的處理。這就是我們可以實現軟體定義功能的地方，因為這個大的中央計算機沒有具體的工作要做。它做任何執行在它上面的軟體告訴它要做的事情。這就是你將開始在大型中央計算單元上引入軟體定義的功能。”
擴大銷售
而這正是架構變得真正有趣的地方。Day說：“如果一切都由軟體定義，這個東西看起來更像你的手機或電腦，就在上面執行不同的應用而言，往往是在同一時間。而且，這些軟體應用正在定義車輛的功能。這就是軟體定義的汽車。因為OEM可以讓一輛汽車的功能是由軟體完成的，你將在上面執行。你可以有相同的平臺，為高階車提供高階功能，為低端車提供基本的功能，而算力可以保持不變。從架構上看，這可能意味著開發者可能會選擇一開始就配置硬體冗餘，因為軟體定義功能的另一個關鍵是它們也可以升級（有點像你的手機或電腦）。因此，汽車從離開經銷商到你賣掉它時並不是保持不變。它實際上會成熟、升級，或變得更好，不斷演變的。”
他指出，這在消費類電子產品中得到了很好的理解。“作為使用者，現在已經非常習慣了，因為這就是我們在個人裝置領域中的做法。這對汽車來說又有什麼不同呢？由於你並不真正知道哪些應用可能會在上面執行，或者這些應用會對效能產生什麼影響，這意味著你可能想從一開始就對中央計算進行過度配置。你說，‘我希望這個硬體在汽車的使用壽命內一直可以有效工作‘。比方說是五年。你可以說，‘儘管我現在不一定需要所有的效能，但我們很有可能會有另一個應用，比如更先進的ADAS功能的出現。我們仍然會使用現有的感測器，因為我們將在車輛中安裝各種不同的感測器，但它要實現的實際功能在未來可能會比現在更先進’。”
為了實現這一切，Cadence的Schirrmeister指出，車輛必須能夠進行OTA更新。“但是你真的不希望弄壞你的汽車，就像有時手機升級不成功就會出毛病一樣。這意味著很多事情都必須以非常詳細和安全的方式來考慮。但你也可以進行與安全有關的更新，比如更好的障礙物識別的演算法等，因為這些都不是靜態的。這些都需要在複雜性的驅動下進行組織變革。這也是在改變思維方式。汽車正在進一步消費化，消費者世界中的各種升級，如電視、遊戲機、手機的升級，在這個意義上，汽車被消費化，也成為一種消費類產品。它是使用者互動的終端之一，這是一個要在裡面放多少消費者體驗的問題。但這絕對是一種消費化。”
供應鏈的顛覆
Elektrobit的軟體架構主管Moritz Neukirchner指出，向軟體定義汽車轉變的另一個方面是創造價值。“你認為汽車的創新是在哪裡進行的？我們主要關注的是創新，透過軟體在汽車領域取得進展，無論是在功能層面（如何開發應用或ADAS系統），還是在如何實際構建和維護軟體。車輛是如何整合的？以前，我們是把盒子放在一起，用線束連線。現在我們非常關注把軟體元件結合在一起，把它們作為軟體部分進行整合，能夠單獨更新這些元件，而不是更換車輛中的單個盒子，這樣整個開發實踐就會發生變化。這種方式不太關注機械方面，不太注重購買盒子或線束，而是更注重如何把功能放在一起，如何從邏輯的角度構建功能，因為它是由軟體驅動的。”
Neukirchner說，所有這些都必須預先考慮到安全、資訊保安、自動駕駛、資訊娛樂等問題，同時還要考慮到維護和保持創新生命週期的良好控制。“OEM現在在軟體方面擁有更多的所有權。基本上每個OEM都是這種情況。每家都在建立自己的、甚至有時是一個獨立法人，來開發軟體。否則就是OEM內部的大型部門正在掌握軟體平臺的所有權。我們還看到一個趨勢，一些OEM想增加他們的IP和軟體，他們想了解如何進行軟體整合，而不是從Tier 1採購盒子。我們還看到在汽車作業系統中，有一種趨勢是直接從中介軟體供應商那裡採購，而不是去找Tier 1，所以汽車供應鏈正在被顛覆。”
汽車OEM希望能夠預測潛在的問題，特別是確保中央計算系統不會出現故障或受到任何影響。這正在改變OEM的思維，反過來也改變了整個供應鏈。
Arm的Day指出，這使系統中的責任發生了一些轉移。“這不是關於這一個硬體模組必須如何表現的問題。關鍵在於軟體在上面的行為。例如，你可以有一個硬體平臺，而這個硬體平臺有足夠的效能來執行資訊娛樂和ADAS系統。至於這些東西如何執行，實際上將由軟體定義。假設我需要這些東西相互獨立，即使它們在同一個硬體系統上執行。這可能意味著我需要引入一個hypervisor來隔離這些東西，使其不受干擾。但我也需要能夠讓我的軟體工作負載輕鬆地在這些東西上執行和離開。這看起來像什麼呢？這是一個軟體架構與硬體架構的權衡。你仍然需要為硬體系統提供可靠性、認證等，但它的功能和內容將由軟體來定義。這就是一個重大轉變。你需要確保它能夠可靠地執行。你可能仍然想把冗餘元素放入其中，無論是在SoC本身還是與多個SoC。但這裡有一個有趣的潛力，即實際上可以改變應用。”
未來前景
軟體定義的方法也增加了系統的複雜性，並使工程團隊的工作更加困難。
Synopsys的Serughetti說：“複雜性在增加，而與此同時，設計工程師的開發效率並沒有真正提高。工程師看著這個艱鉅的任務，現在還得考慮所有的東西是如何協同工作的，包括進行800萬英里的實車測試。從這個角度來看，對開發方法有影響，不僅是軟體和整合，而且在SoC架構方面，從定義SoC的角度來看。工程團隊必須在非常早期的時候對架構進行效能和功耗方面的探索。正因為如此，晶片開發商、Tier 1和OEM之間的合作變得越來越重要。每個人都在研究需要什麼型別的SoC。OEM需要自己造晶片嗎？他們要與晶片供應商合作來定製晶片嗎？”
在這裡，挑戰是用例，驅動SoC效能的工作或工作負載。Serughetti解釋說：“我如何儘早驗證或探索，以便在我的SoC中實現合適的效能？這是架構發揮作用的另一個方面，從SoC架構一直到不同計算元素之間的整車級的架構。合作元素不能被低估。以前，很多開發可以獨立完成。現在至關重要的是，開發是在生態系統內協作完成的，而這種協作需要有基礎設施來支援。你如何交換資料？你如何將你正在做的事更多地轉移到一個可執行的規範？今天的系統更加複雜。你不能透過一個電子表格來做這件事。你真的必須有一個協作平臺來開展。這是消費類電子行業的人們的日常活動，他們將受到這種向軟體定義方法轉變的影響。”
Arteris IP的CMO Michal Siwinski同意，從根本上說，汽車開發將是軟體定義的。但他指出，軟體和硬體的比例仍在界定之中。“在Chiplet的背景下，晶片可能會改變一些軟體定義的汽車中發生的情況。記住，電源管理曾是晶片的一部分。然後它脫離成為一個獨立的晶片。現在，隨著我們進入chiplet，記憶體可能在5nm，數字內容可能在4nm，模擬可能在28nm，MEMS在130nm，誰知道天線會在哪個工藝中節點？突然間，它又回到了SoC的異構計算。一些離開晶片的部件可能會回到這個更大的晶片中，因為你仍然希望接近和最佳化。同樣，一些純軟體的東西，或更多的軟體驅動的東西，實際上可能會在硬體中找到他們的方式，因為你有更好的控制，同時仍然是軟體控制的。時間會證明一切。”