嵌入式控制系統設計/汽車

的Wikibook 嵌入式控制系統設計

引言

對於嵌入式汽車系統的設計，整個車輛系統通常被分成四個不同的功能區域，這些區域可以在設計階段進行分離。

• 底盤
• 傳動系統
• 車身
• 遠端資訊處理

這些區域中的每一個都將具有不同的優先順序和需求，並且這些區域通常也會由不同的設計團隊負責。需要指出的是，雖然這些區域在過去是完全分離的，但新的功能和法規正在迫使這些不同的區域相互通訊。這些區域的設計需求差異很大，區分由於法規而產生的需求和由於競爭而產生的需求至關重要。傳動系統和車身（被動安全）區域的大量需求將是由於法規造成的，因此可以被認為是硬約束。另一方面，底盤和遠端資訊處理的許多需求是由於製造商之間的競爭造成的，並提供了更大的設計自由度。

系統需求

本節不會詳細闡述所有不同車輛系統的不同功能需求。而是概述車輛最重要的系統級需求，以及這如何影響嵌入式控制系統的需求。

• 安全性

對安全性的需求將對傳動系統和底盤的嵌入式系統施加一些重要的功能和非功能約束。這些需求通常不是由法規驅動的，而是由製造商之間的競爭驅動的。

• • 硬即時約束：所有與安全相關的系統都必須遵守即時約束，這一點至關重要。諸如ABS之類的系統應該能夠在幾毫秒內做出反應，以確保及時干預。這不僅對處理器的速度提出了約束，而且對整個汽車中使用的通訊系統的速度也提出了約束，因為這些系統通常依賴於來自其他系統的輸入訊號，並且還需要向其他系統傳送輸出（例如，電子穩定控制系統必須與發動機管理系統通訊）。
  • 故障檢測：安全關鍵功能的每個子系統都應該能夠自動診斷其功能，並且在發生故障時應該能夠切換到安全關閉狀態。顯然，通訊系統也應該能夠執行資料傳輸檢查。法規規定，如果檢測到故障，也應將其顯示給駕駛員（故障指示燈）並將其儲存在控制器的故障儲存器中。
  • 冗餘：關鍵感測器，如線控油門系統中的節氣門，應具有冗餘性，以最大程度地降低故障機率。
  • 復位時間？啟動時間？
• 成本

與所有行業一樣，製造成本在汽車行業也非常重要。

• 排放/燃油經濟性

排放約束背後的主要驅動力一直是法規，儘管最近燃油經濟性已成為越來越重要的銷售論據。這項法規的一個非常重要的方面是車載診斷（OBD），它持續監控發動機系統以確保日常使用符合排放法規。傳動系統的一些最重要需求是

• • 監控與排放相關的電氣元件（例如，短路）並存儲故障（OBD 1）。
  • 監控系統功能（例如，感測器訊號的合理性檢查）（OBD 2）
  • 必須監控用於監控影響診斷的與排放相關的元件的元件。（OBD 2）
  • 監控頻率通常由法律規定。
  • 故障必須透過故障指示燈（MIL）顯示給駕駛員。
• 上市時間

對縮短上市時間的推動使系統開發朝著更多可互換元件的方向發展。這目前非常困難，因為沒有明確的通訊標準。匯流排通訊系統使得將新功能引入現有系統變得更加容易。

• 乘客舒適度

由於競爭的原因，乘客舒適度在汽車行業也非常重要。這些需求主要適用於內部和遠端資訊處理領域的系統。這也對嵌入式系統施加了一些約束。

• • 軟即時約束：許多非關鍵系統（例如，電動車窗，電動後視鏡……）都規定了定時約束，但是違反這些約束不會產生嚴重影響。例如，許多此類系統必須在100毫秒內做出反應，這是人類可以感知的延遲限制。

設計流程

汽車中的嵌入式系統通常遵循模型驅動設計工作流程（如設計流程一節中介紹的那樣）。

功能需求通常應在功能設計階段予以考慮。這還包括故障安全模式。

應在實施階段考慮定時約束。確保硬體能夠達到定時約束非常重要，但也不要效能過高。還應在此階段考慮對通訊速度的需求。如果通訊速度非常關鍵，甚至可能需要在原始車輛模型中包含通訊網路的詳細模型。所有用於監控硬體故障的功能也只有在此階段才能設計。必須滿足即時約束的關鍵功能通常需要其自身的硬體來確保即時執行，因此這是一個從設計開始就應考慮的約束。在實踐中，這可能非常困難。

一個非常重要的設計階段是配置不同車輛系統之間的通訊。由於訊號數量不斷增加且缺乏標準化，這目前非常耗時。AUTOSAR標準旨在極大地促進此階段。

硬體

最初，汽車配備了單一訊號電纜。隨著電子系統數量和複雜性的增加，這種方法由於成本、重量和複雜性的原因不再可接受。這就是為什麼製造商轉向車載匯流排系統（例如CAN匯流排）來實現不同系統之間車載通訊的原因。一輛汽車中通常有多個匯流排，每個系統都適應特定系統組的速度需求。有關這些匯流排系統的更多資訊，請參閱有關現場匯流排的章節。

目前，大多數功能都程式設計在帶有程式儲存器（EPROM或快閃記憶體）的微控制器中。由於功能種類繁多，現代汽車中也存在各種感測器。安全關鍵元件（如ESP感測器）上的感測器也需要具有內部自監控功能。

Autosar

當前問題

當前的車輛系統以專有解決方案為特徵：不同車輛系統中的應用程式使用其他介面或其他通訊標準。這導致供應商為每個系統開發和維護單獨的軟體，而不是在每個系統上使用相同的軟體並處理通訊、功能和訊號定義的相容性問題。

原始裝置製造商 (OEM) 負責整合不同的系統並保證整合系統的確定性執行。這項任務常常因不同供應商的應用程式所使用的不同診斷服務而變得複雜。隨著嵌入式控制系統數量和互動程度的增加，專有解決方案的進一步擴散將需要更多資源，並且保證整合系統的確定性執行將變得更加困難。

此外，還有一個趨勢是為客戶提供更大的靈活性；客戶希望從不同的選項中進行選擇。這導致了一個基本車輛系統出現許多細微的變化，這在現代模組化和實現靈活性水平較低的系統中需要大量的設計工作。

為了解決這些問題，汽車製造商、供應商和工具開發商聯合起來開發了一個新的標準。該專案名為 AUTOSAR，它是 AUTomotive Open System Architecture（汽車開放系統架構）的首字母縮寫。在 AUTOSAR 的維基百科文章 中，解釋了 AUTOSAR 的目標和技術資訊。

AUTOSAR 標準

AUTOSAR 標準旨在成為一項突破，它應該能夠實現車輛系統設計的正規化轉變，並帶來功能改進和更高的安全性。

術語

AUTOSAR 專案引入了自己的術語，這些術語將在本文的其餘部分使用。更多資訊可以在 AUTOSAR 的維基百科文章 中找到。

AUTOSAR 方法：一種四步方法，可用於從設計模型開始建立車輛系統架構。

基礎軟體：標準化的軟體，不包含任何對終端使用者可見的功能，但提供硬體相關和硬體無關的服務。

執行時環境：在軟體級別實現可能的通訊路徑。

應用軟體：實現實際功能的軟體，這些功能對終端使用者可見。

標準分析

可重用性

AUTOSAR 專案選擇標準化通訊和非功能性軟體，例如執行時環境和基礎軟體。功能軟體，即應用軟體，僅透過其介面進行標準化。

這有幾個影響

• OEM 可以透過為每個特定應用程式選擇最佳的軟硬體來構建車輛系統，而無需擔心相容性問題。這意味著整合成本降低。此外，維護更容易執行，因為可以為所有應用程式標準化診斷服務，而不是依賴於供應商。
• 供應商仍然可以在應用軟體元件的實現方面進行競爭。這應該會導致更好的元件。同樣，由於介面清晰，供應商可以為所有不同的車輛系統構建、除錯和維護其應用軟體的一個版本，從而減少軟體的擴散。由於介面清晰，在供應商之間或供應商團隊之間劃分開發也有更多選擇。
• 硬體供應商仍然可以在最佳硬體方面進行競爭，僅用於使用硬體的必要基礎軟體將被標準化，但將有選擇來保護特定軟體（例如，用於消除執行器非線性效應的特殊軟體）。
• 由於定義明確的領域，新公司可以輕鬆進入市場。一家公司只需要在其領域成為專家即可。

安全性

為了提高根據 AUTOSAR 標準設計的車輛系統的安全性，包含了一些安全措施。

• 安全完整性功能，這些功能是 AUTOSAR 中必須具備的安全措施，獨立於應用上下文。這些功能支援應用功能和安全功能的正確執行。通常，這些功能與資源保護、監控和自檢有關。由於 系統複雜性 的變化，需要採取此類別的額外安全措施。例如，如果兩個應用程式可以使用相同的資源並共享記憶體，則需要構建一些安全措施；例如，防止寫入其他應用程式的資料段。
• 支援依賴於應用程式上下文的安全功能。這意味著支援來自不同應用程式的系統中典型的安全功能，例如關鍵應用程式的快速重置。
• 通用安全要求，例如在不傳播的情況下本地檢測故障。

安全功能可以自動新增到所有車輛軟體中，這與現有的車輛軟體設計方法相比是一個很大的優勢。

標準和介面的清晰集合減少了由於應用程式之間錯誤互動而導致故障的可能性。

AUTOSAR 中的設計

基於元件的設計

AUTOSAR 專案在車輛軟體設計中引入了基於元件的軟體設計概念。由於車輛系統日益複雜，因此需要進行此更改，這導致需要團隊合作。

• 在基於元件的設計中，每個元件應該做什麼很清楚，因此設計可以輕鬆地劃分為不同的團隊。此外，介面是標準化的，這保證了資料交換的一致性。
• 元模型 簡化了團隊合作。車輛系統的正式描述確保了資訊的結構可以清晰地視覺化，並保證了資訊的一致性。
• 基於元件的軟體設計促進了基於模型的設計的使用。因此，可以擴充套件基於模型的設計的使用，這是車輛系統設計中的當前標準。
• 基於元件的設計使汽車軟體開發從基於 ECU 的方法轉變為基於功能的方法，並使編寫獨立於所用 ECU 的應用程式軟體成為可能。

系統設計的四個基本“關注點”

由於車輛系統的複雜性不斷增加，因此需要明確控制互動過程，而不是隱式定義嵌入在不同子系統本身中的互動。

在這種情況下，引入了 系統設計的四個基本“關注點” 的概念。這些代表了互動過程中的不同層次。

明確的層級由於更好地概述了互動過程而促進了車輛系統的設計。特別是車輛系統的變化，這需要協調方面的變化，將更加直接。

• 通訊取決於所使用的協議、介面以及有關資料交換格式的約定。這在標準中有所規定。
• 計算取決於應用軟體元件。
• 配置取決於系統設計人員和用於該方法的工具鏈。系統設計人員設計 ECU 網路的物理拓撲結構，並決定要向車輛系統新增哪些應用程式。在遵循該方法時，所選工具鏈中的最佳化演算法確定不同應用程式在不同 ECU 上的分佈。
• 協調在 執行時環境 中指定。執行時環境是配置的實現，能夠管理 ECU 間和 ECU 內通訊，並且可以呼叫不同的應用程式以在其通訊埠處理通訊。

應用軟體僅影響計算步驟，因此不知道計算和配置層。這使得建立不知道互動夥伴數量的應用軟體成為可能。這樣，通訊和功能之間就有了明確的區分。

互動的明確控制使得可以向車輛系統新增應用程式，而無需更改與新應用程式互動的某些應用軟體。必要的更改位於執行時環境中，在使用 AUTOSAR 方法時，在 ECU 配置步驟中會自動調整執行時環境。

對系統複雜性的影響

AUTOSAR 標準也改變了 車輛系統的複雜性。現代車輛屬於分散式硬體分散式軟體型別。

AUTOSAR將系統視為在單個虛擬平臺上執行的不同應用程式。該標準使得將虛擬平臺轉換為不同ECU上的實際實現成為可能，其中一些應用程式可能執行在同一ECU上。這種方法為轉向分散式硬體-集中式軟體的系統鋪平了道路。

這種新的車輛系統模型對安全有一些影響。

從實際的角度來看，ECU的共享也是必要的。車輛中嵌入式控制系統的數量不斷增加，但車輛中ECU的數量正在達到極限。成本過高，車輛空間有限。透過AUTOSAR提供的虛擬化工具，可以在ECU上嚴格分離功能，而不會損失安全性。這可以為減少（但更強大）的ECU開啟道路。

實際方面

整車廠

Autosar標準化是車輛系統設計方法的重大改變。這使得將現有車輛系統適應Autosar相容架構變得困難。根據Autosar核心合作伙伴的推廣計劃，整車廠不會在一天內切換到Autosar相容系統，而是會從在一個經典設計的E/E架構中為一個大型子系統整合一個Autosar相容的ECU開始（引用）。透過這種方式，可以積累經驗，然後整個子系統，最終整個車輛系統都可以變得與Autosar相容。

供應商

缺乏現有的Autosar相容車輛系統使得供應商難以測試旨在與Autosar相容的新元件。為了解決這個問題，一些公司在專案中聯合起來，生成一個Autosar相容的測試平臺，不同的公司可以在其中測試其軟硬體。例如SWAP專案，其中八家瑞典公司擁有設計專業測試平臺的必要和互補能力，聯合起來。

未來

展望未來，這些趨勢似乎將繼續下去。例如，網路汽車或無人駕駛汽車需要了解整個車輛的狀態才能以最佳方式控制車輛。只有當存在集中式軟體時，這才能實現。

在遙遠的未來，汽車之間以及汽車與道路基礎設施之間的通訊可能會成為一種趨勢。

例如，網路汽車車隊。這樣的車輛車隊在一個道路網路上形成一個管理的運輸系統，用於乘客或貨物，具有按需和門到門的運輸能力。 這種型別的系統屬於“分散式硬體-集中式軟體”類別。車隊問題主要涉及以下要素： - 將車輛分配到特定需求，- 行程結束後重新分配車輛，- 避免死鎖，- 需求管理和票價收取，- 分散式與集中式管理，- 通訊架構。

除了由中央管理系統控制的車隊之外，還可以想象，人們也會尋求僅與其周圍環境以及可能收集交通訊息的中央系統通訊的自動駕駛汽車。然後，這輛汽車可以自主決定應該採取什麼行動。

梅賽德斯-賓士目前正在開展這方面的實驗。他們的工程師正在開發一個名為“互動式車輛通訊”的系統，該系統允許汽車相互通訊。他們研究的現狀體現在他們的概念車“ESF”中。不同汽車之間的資料交換是透過車輛之間在短距離內形成的“臨時”網路進行的。這些WLAN不需要額外的外部基礎設施。傳輸頻率為5.9 GHz，距離最遠可達500米。當然，如果不同的汽車相互通訊並將訊息傳遞給對方，則此距離會擴充套件。

目前，法蘭克福有一個名為“simTD”的專案。 不同的德國汽車製造商參與了這項測試，最多有400輛汽車相互通訊。這項測試的主要目的是提高道路安全。

參考文獻

嵌入式控制系統設計