現代汽車系統仰賴分散式 ECU,可跨網路 (例如 CAN、LIN 與汽車乙太網路) 交換資料,因此通訊行為對整體系統功能至關重要。然而,在開發階段,完整的車輛系統很少可用,因此工程師無法驗證 ECU 之間的互動。這種情況往往會導致整合時間延後、測試涵蓋範圍縮短,以及增加後期問題的風險。
Restbus 模擬可重現遺失網路節點的通訊行為,進而實現實際且可重複的測試環境,以因應這方面的挑戰。隨著車輛網路日益複雜,並採用 AUTOSAR 架構通訊,因此需要可擴充的資料庫導向方法,以確保 ECU 驗證準確可靠。NI VCOM 可直接從車輛資料庫執行訊號架構 Restbus 模擬,以滿足此需求,為 CAN、LIN 與汽車乙太網路環境中的 ECU 驗證提供一致且可維護的基礎。
VCOM Restbus 模擬的準確度直接取決於其建立所依據之通訊資料的品質。VCOM 不需要手動開發的通訊模型,而是直接從車輛通訊資料庫執行行為,讓資料庫成為整個測試環境的基礎。
VCOM 中的 Restbus 模擬完全由定義網路、節點、協定資料單元 (PDU)、框架、訊號、時序與保護規則的通訊資料庫驅動。VCOM 支援 DBC、LDF 與 AUTOSAR ARXML 格式。
在現代車輛程式中,AUTOSAR ARXML 是 Restbus 模擬的主要來源,因為它描述了車輛網路間的通訊關係。為了準確模擬,VCOM 需要包含所有相關通訊參與者的系統層級摘要。由於 Restbus 行為需視傳輸和接收關係而定,因此,單憑 ECU 提取通常並不夠。
實務上,ARXML 檔案通常必須先檢視並清理,才能使用。VCOM 提供的架構可將這些資料庫定義轉換為可執行的 Restbus 行為,有助於讓測試環境與預期的車輛通訊架構保持一致。
現代 ECU 幾乎不會以隔離方式運作。在 HIL 與平台測試期間,工程師必須複製車輛網路行為,以便在實際條件下驗證 ECU 功能。
VCOM 軟體套件可提供訊號架構的 Restbus 模擬,適用於 HIL 與平台測試系統。此系統以 NI-XNET 驅動程式層為建置基礎,可直接從車輛資料庫執行通訊,重現遺失網路節點的行為,以便工程師在完整車輛系統可用之前先驗證 ECU 功能。VCOM 可處理時序、訊息封裝與保護機制等特定協定細節,讓工程師能專注於 ECU 驗證,而非通訊實作。
VCOM 使用適用於 CAN、LIN 與汽車乙太網路的 NI-XNET 介面,在 Microsoft Windows 電腦與 NI Linux RT 系統上執行,因此可部署於開發台與機架架式 HIL 環境中。可選的診斷 (UDS) 與量測與校準 (CCP/XCP) 工具組,可進一步擴充測試自動化功能。
VCOM 不會仰賴客制化編碼通訊邏輯,而是會直接從匯入的資料庫來得出所有傳輸與接收行為。每個模擬網路節點都能完全按照既定的定義運作 (使用已設定的網路、時序參數與保護規則),不需要工程師手動執行協定行為。
對於 CAN，傳出的訊框係透過對訊號值進行編碼而產生，編碼時依據各訊號的比例係數、偏移、位元配置、位元組序，以及任何相關的總和檢查碼、計數器或 AUTOSAR 端對端保護機制。傳入的框架已解碼為訊號,並可供測試邏輯、指令碼或觀察員使用。訊息時序非常明確,包括具有定義週期與偏移的循環傳輸,以及狀態變更或外部要求所觸發的事件導向傳輸。
在 LIN 中,框架排程會控制哪些框架顯示在哪個插槽中,以及何種速率。在汽車乙太網路上,VCOM 會根據 ARXML 所定義執行 SOME/IP 通訊,包括服務探索、事件傳輸,以及適用的呼叫方式。在所有情況下,VCOM 均會執行通訊規格,但不會執行 ECU 內部行為。
假設受測的引擎控制器會根據通訊規格消耗 Restbus 的 Motor_Speed,並且傳輸轉矩要求與限制位置訊息。
在平台上,Motor_Speed 會透過 Restbus 模擬來驅動從閒置到紅線,而外部氣溫模型則會從冷啟動轉換為正常作業條件。VCOM 會編碼與傳輸所有 Restbus 通訊,完全符合資料庫中的定義,包含時序、調整、計數器與保護。
為了評估穩定性,測試會導入受控的干擾,當中的「Motor_Speed 訊息百分之五」會掉落一秒。在通訊層級,必須嚴格遵守成功標準。引擎控制器必須在故障發生 100 毫秒內,執行已定義的安全策略,並在有效的流量恢復後 200 毫秒內恢復正常運作。恢復後,診斷錯誤碼不會保持有效。
此情境說明了典型的 Restbus 使用案例。VCOM 提供通訊內容與故障植入點,而 ECU 行為與實體模型則會保持在 Restbus 模擬之外。
VCOM 支援現有與新興車輛方案常用的協定。如此一來,單一 Restbus 環境即可重現與受測 ECU 相關的網路行為,不需要針對各協定另行工具。
支援的協定包括 CAN、LIN 與汽車乙太網路。就汽車乙太網路而言,SOME/IP 通訊會受 ARXML 提供的服務定義所支援,包括必要的服務探索機制。J1939 可支援重複用途的基本多工與網路管理。
傳送行為會從資料庫定義中自動得出,包含循環訊息、事件導向訊息與自發訊息。VCOM 原生執行多工 PDU、容器 PDU 與 AUTOSAR 通訊架構,讓您可執行複雜的系統定義,不需手動編寫協定編碼。計數器訊號、CRC 與 AUTOSAR 端對端保護設定檔會在執行階段自動產生並評估,能發揮精確的高效能執行效能,避免客制化使用者程式碼所帶來的延遲、CPU 負載與維護負擔。
訊號值可透過 API 寫入或置換,以驅動測試情境,同時系統會持續採用保護機制。
車輛程式在 ECU 驗證期間必須具備通訊完整性機制,並且能夠正常運作,而不限於生產階段。VCOM 會將這些需求視為 Restbus 正常執行的一部分,而非個別的工程作業。
VCOM 實作了內建的安全內建通訊 (SecOC) 設定檔,適用於數個 OEM,且可隨選提供額外的設定檔。檢查號、計數器與 AUTOSAR 端對端保護設定檔會根據隨附於每個 PDU 的通訊規格,自動計算。
若是需要連結層級安全的汽車乙太網路設定,支援的 NI XNET 乙太網路介面可啟用 MACsec。在這些配置中,VCOM 會繼續在應用與 PDU 層級運作,而驅動程式與硬體則會以透明透明的方式處理加密與連結保護。
要讓受測 ECU 正確運作,周圍網路必須反映實際狀態轉換。若 Restbus 環境不考量休眠、覺醒與網路模式轉換,可能會產生不存在於實際車輛中的測試條件,進而導致誤導性結果。
VCOM 會根據資料庫中的定義,針對 CAN 與汽車乙太網路執行 AUTOSAR 網路管理行為,確保受測 ECU 在節點的狀態之間轉換時,會感知到一致的系統環境。
TC10 等汽車乙太網路的實體休眠與喚醒機制,均由 NI XNET 驅動程式與所支援的硬體負責處理。VCOM 會在這個層以上運作,並針對造成的網路狀態變化做出反應,而不會直接控制實體警示行為。
VCOM 的設計旨在整合於現有的 HIL 與平台環境,而不是取代這些環境。在一般的 HIL 設定中,VCOM 會同時部署至系統層級的工具,例如 NI VeriStand 或 NI LabVIEW。這些環境可控制測試執行,並透過 VCOM API 與 Restbus 執行模擬互動。操作包含開始與停止模擬、讀取與寫入訊號值,以及回應網路事件。
VCOM 提供 Restbus 模擬層,以及可選的診斷與校準功能。NI-XNET 提供實體 CAN、LIN 與汽車乙太網路介面,並以與車輛相同的方式連接 DUT。WebUI 支援資料庫偵測與即時流量監控,可簡化平台上線與除錯作業。
隨著車輛通訊網路日益複雜,開發與維護 Restbus 模擬的所需心力往往會成為瓶頸。在許多測試環境中,通訊行為會透過客制化指令碼或特定應用程式的邏輯來執行。雖然此方式對個別平台相當有效,但隨著通訊定義不斷演進,要在多個測試系統之間保持一致性也變得越來越困難。
VCOM 透過資料庫導向方法因應此挑戰。通訊行為會直接從 DBC、LDF 與 AUTOSAR ARXML 定義執行,包括訊號編碼、時序、多工、計數器、CRC 與 AUTOSAR 保護機制。當通訊需求發生變化時,工程師會更新資料庫定義,而不會修改跨多個測試台的通訊邏輯。
這種方式在擴充驗證活動時特別重要。已於開發台上驗證的 Restbus 設定,可使用相同的通訊定義與行為,部署至其他 HIL 系統。由於通訊執行作業仍與資料庫息息相關,因此,所有平台都會透過共通的資料來源運作,進而降低因獨立維護的指令碼或設定而造成不一致的風險。
VCOM 專案可在 Windows 與 NI Linux RT 系統上執行,並透過常見 API 與 LabVIEW 與 VeriStand 整合。這樣一來,即可在桌上型、機架式與自動化測試環境之間重複使用通訊設定,同時維持網路行為一致。
隨著測試產能的增加,產能不但提升,還能提升可重複性與可追蹤性。工程作業可以繼續集中在 ECU 驗證與測試範圍上,而不是跨平台維護通訊基礎架構。
在新的平台上部署 VCOM 需要一組可預期的早期驗證步驟。下方指南將反映常見的上線模式,並協助團隊有效率地從初始設定轉移至驗證通訊行為。
在車輛程式中保持準確且一致的 Restbus 模擬是持續的工程挑戰,這項挑戰會隨通訊定義不斷演進、測試台越來越多,而且協定複雜度也越來越高。
挑戰很少在於通訊協定本身。更常見的工程作業是要在不同的專案中保持模擬邏輯、同步化測試平台、處理資料庫修訂,以及執行訊號編碼、計數器、CRC、網路管理與保護機制等協定細節。
VCOM 透過資料庫導向的通訊架構,因應這些挑戰。VCOM 可直接從 DBC、LDF 與 AUTOSAR ARXML 定義執行通訊行為,為 CAN、LIN、汽車乙太網路、SOME/IP 與 J1939 通訊提供一致的架構,同時自動管理時序、多工、計數器、CRC、AUTOSAR 端對端保護與支援的 SecOC 設定檔等特定協定特定行為。工程團隊不需要開發和維護客制化通訊實作,而是要以單一通訊基礎進行標準化,以符合不斷演進的車輛網路定義。
由於驗證活動會擴大至多個團隊、專案與測試環境,因此,這種架構的價值也越來越高。相同的通訊設定、API 與自動化工作流程可部署於桌上型開發系統、HIL 平台與自動化測試基礎架構中,進而減少重複作業,同時協助確保驗證流程的一致性。
實務上來說,這項做法有助於:
此值的延伸範圍超過模擬網路流量。VCOM 提供可擴充且可維護的通訊基礎,可減少工程負擔、提升驗證環境之間的一致性,並讓團隊能將心力集中在驗證 ECU 功能上,而非管理通訊基礎架構。