當前的駕駛員輔助功能，例如高速公路的自動停車或交通擁堵輔助和車道偏離警告系統，是邁向自動駕駛的第一步。但就未來幾年預期的驅動功能而言，今天的系統架構已經達到了極限。控制設備日益增長的互連性及其日益復雜的功能需要在開發和跨功能、跨車輛軟件平臺方面采用集成系統方法。

許多駕駛員輔助功能今天已經可用。但根據法律，司機仍然不能完全依賴這個系統。如果發生錯誤（例如，傳感器發生故障），他們必須能夠立即重新獲得控制權。

未來的駕駛員輔助功能將為駕駛員提供新的自由，因為車輛操作員將能夠轉移他們對交通的注意力并傾向于其他活動。他們將被允許松開方向盤，激活輔助功能，還可以在交通擁堵時進行視頻通話，而不是全神貫注于交通。

奧迪宣布其 2017 款車型的交通擁堵輔助系統等系統將為駕駛員提供更多時間來控制車輛，因為最初駕駛員將有長達 10 秒的時間重新指揮他們的車輛。但是，這也意味著駕駛員可以在輔助功能激活時關注其他事情，這意味著如果發生系統故障，他們將無法使用。在此期間，車輛將負責避免或處理危險情況，因為在完全控制權交還給駕駛員之前，它無法在出現錯誤時簡單地關閉。相反，他們必須保持最低水平的功能，以保證車輛和車內人員的安全，所以，事實上，

【圖1 | 實現自動駕駛汽車的各個階段都需要改變系統架構。］

轉變始于發展

雖然車輛基礎設施、硬件和軟件都必須經過精心設計，即使在系統出現錯誤的情況下也能正常工作，但在向自動駕駛緊急功能過渡的初始過渡中，可能會有一個初步的范圍——例如，進入保險箱、帶有警告信號閃光燈的慢停。這種“安全狀態”在交通擁堵的情況下已經足夠了，但在正常交通情況下，系統必須安全地開車到最近的緊急休息區或從下一個出口安全停車。

根據發生錯誤時所需的功能范圍，必須涉及許多子功能和相關的傳感器、執行器和軟件計算。為了能夠實現具有自動駕駛所需的可用性和可靠性的功能，需要修改系統架構。

控制設備暫時仍將是經典開發，因為駕駛員輔助功能的實現是靜態的并且遵循特定的模式：導入傳感器數據、計算控制設定點、控制執行器。然而，在未來，開發團隊將被迫在系統級別實施越來越多的解決方案。單個控制設備將離開中心舞臺，整個系統將成為焦點，因為如果原始執行硬件發生故障，通信路徑必須能夠改變并且軟件功能必須由其他硬件實時執行。

實現實際系統級輔助功能的要求越來越嚴格，傳感器和執行器在網絡中的復雜性也在增加。對能夠實時執行復雜計算的高性能處理器的需求不斷增長，軟件元素還必須滿足嚴格的安全要求，最高可達汽車安全完整性等級 D （ASIL D），即汽車的最高軟件安全等級。

在最佳情況下，汽車行業利用的計算機架構將以一種使功能獨立于硬件的方式實現，因此安全關鍵軟件不必經過特殊調整即可在充當駕駛員執行平臺的異構控制器架構上運行未來的輔助系統。理想情況下，開發人員不需要知道他們的共享功能將在何處以及如何執行。

修改后的系統架構

這種平臺的一個例子是 NVIDIA DRIVE PX，它由兩個 Tegra K1 處理器作為性能控制器，一個英飛凌 Aurix 處理器作為安全控制器，并支持 Elektrobit 的 EB tresos 軟件環境。EB tresos 基于稱為 AUTOSAR 自適應平臺的汽車開放系統架構 （AUTOSAR） 標準的變體，并為 Tegra 處理器上的動態操作系統（在本例中為 Linux）形成運行時環境。

Elektrobit 開發的駕駛員輔助應用程序框架是在該系統上運行的應用程序。該框架實現了用于融合傳感器數據、軌跡規劃和控制的模塊，以及用于同步和協調多個駕駛員輔助功能的標準機制，作為“情況和決策”模塊的一部分。在框架中運行的輔助功能（例如自動停車功能）依賴于底層 EB tresos 基礎設施提供的安全機制，因此功能管理和合規性監控軟件以及錯誤處理可以不受干擾地運行安全控制器本身。這保證了可靠的操作，并且還可以在控制設備上運行具有高 ASIL 等級的軟件，同時具有高性能，

【圖2 | 軟件層與高性能硬件平臺（例如 NVIDIA DRIVE PX）相結合，是集成系統方法的基礎。］

借助 DRIVE PX 上的 EB tresos 環境等動態軟件平臺，各個功能之間的通信路徑是透明且靈活的。應用程序是使用經典的 AUTOSAR 運行時與控制設備上的環境進行通信，還是通過適當的軟件層動態建立和取消與隨機發送器和接收器的通信，這與未來的應用程序無關。這種通信靈活性支持“故障運行”系統所需的冗余機制，例如，通過實現熱備用功能。熱備用意味著可以在其他硬件環境中使功能成為冗余，這些硬件環境處于備用狀態，并且僅當功能在主環境中發生故障時才激活。這些額外的硬件環境將 CPU 時間和內存等資源用于特定功能，因此并行運行。這導致快速切換能力，從而傳感器和執行器信號根據功能運行的位置動態重新路由。

【圖3 | 動態控制設備架構保證了專用功能范圍的可靠性。］

集成開發和“整車操作系統”

在允許所描述的動態行為的控制設備架構中，您可以通過在系統級別智能連接多個此類控制設備來保證專用資源的可用性，以便功能可靠地執行，而與發生的錯誤或硬件故障無關。然而，這樣做的挑戰在于，它還需要一種系統范圍的軟件基礎架構方法，以便實時動態地管理整個系統。在這樣的實施中，必須集中有關各個控制設備的信息，例如硬件狀態和運行時完整性，以決定如何最好地重新配置系統。

如果將新技術添加到故障操作要求中，例如車輛與其周圍環境之間的永久、持久連接，則此處的需求變得更加明顯。像這樣的在線連接需要修改架構以滿足嚴格的安全要求，以及提供防火墻、訪問控制和入侵檢測工具，以便監控和預防對安全關鍵系統的潛在威脅。

其中許多要求可以通過具有中央控制和分配機制的面向服務的架構 （SOA） 來滿足，但是需要一個新的軟件基礎設施，即“整車操作系統”，將自動駕駛汽車的所有維度集成到未來幾年。使用當今的開發方法實現自動駕駛系統所需的硬件和軟件將是困難的，因為車輛目前由僅與本地功能通信的“孤獨的戰士”控制設備組成。其中一些設備是相互獨立定義的，由汽車制造商的不同部門指定，并由不同的供應商開發。這些設備的軟件部分基于 AUTOSAR 等標準，但通用平臺是未來的解決方案。

向軟件定義車輛的轉變

將自己視為非傳統汽車制造商的新玩家和各種電動汽車初創公司以及主要的 IT 供應商具有為駕駛員輔助等新興系統領域啟動新結構開發流程的優勢。因此，他們將能夠加速汽車系統架構的變革，促使汽車制造商、一級供應商和軟件開發商隨著時間的推移改變實踐。這是設計全新系統架構的唯一方法，為未來的軟件定義車輛基礎設施平臺鋪平道路。

審核編輯：郭婷