汽車診斷的未來：SOVD協(xié)議初探

前言

        在汽車診斷領域，UDS（Unified Diagnostic Services，統(tǒng)一診斷服務）長期以來一直是滿足大多數(shù)診斷需求的核心協(xié)議。然而，隨著 HPC（High-Performance Computing，高性能計算）在新型電子電氣架構中的廣泛應用，傳統(tǒng)診斷方法逐漸暴露出局限性，例如難以高效訪問復雜的軟件數(shù)據(jù)以及靈活適配動態(tài)診斷場景。為應對這些挑戰(zhàn)，SOVD（Service-Oriented Vehicle Diagnostics，面向服務的車輛診斷）標準應運而生，旨在提供更靈活、高效的診斷解決方案。

什么是SOVD協(xié)議

        SOVD 是由 ASAM（Association for Standardization of Automation and Measuring Systems,自動化與測量系統(tǒng)標準化協(xié)會）制定的一種面向服務的診斷標準。該標準將診斷功能和數(shù)據(jù)抽象為獨立的服務資源，利用實體與資源集合進行關聯(lián)和管理。同時，它提供了一套標準化接口，允許客戶端通過標準 HTTP 方法訪問這些資源，從而實現(xiàn)相應的診斷功能。

SOVD的使用場景

        SOVD協(xié)議的應用場景包括：

        · 遠程診斷：通過4G/5G等網(wǎng)絡技術，將車輛與遠程的SOVD Client進行連接，以此獲取車輛的診斷數(shù)據(jù)。

        · 近場/本地診斷：通過無線或有線（如OBD）的方式進行診斷，診斷儀作為SOVD Client去訪問車內(nèi)的整車數(shù)據(jù)。

        · 車載診斷：在車內(nèi)部署SOVD Client，無需與遠程服務器或近場診斷儀永久連接。車載使用場景的結果也可能被近場或遠程使用場景訪問。

        通過以上的場景介紹可以發(fā)現(xiàn)，SOVD協(xié)議有效實現(xiàn)了診斷技術路徑的統(tǒng)一化，可在遠程、近場及車載診斷等不同場景中應用。同時在系統(tǒng)架構層面，SOVD不僅支持部署多個可直接訪問的SOVD Server，還能夠借助SOVD-UDS網(wǎng)關實現(xiàn)傳統(tǒng)ECU的協(xié)議轉換與數(shù)據(jù)訪問，構建了兼具開放性與兼容性的車載診斷體系。這種架構設計顯著提升了各類診斷設備的開發(fā)一致性與互操作性。

SOVD的特點

        · 遵從RESTful原則

        SOVD API 基于 HTTP RESTful 架構設計，提供了 GET、PUT、POST、DELETE 四種方法，使用URI標識資源，通過JSON格式進行數(shù)據(jù)交換?；诖?，我們可以輕松地獲取、更新、創(chuàng)建和刪除汽車診斷數(shù)據(jù)。

        · 結構化數(shù)據(jù)管理

        SOVD將車輛數(shù)據(jù)組織成不同的實體，例如 SOVD Server、Area、Component、App 和 Function。通過實體將不同類型的數(shù)據(jù)分門別類地存放，部分實體間也可以相互關聯(lián)，方便快速找到所需的信息。

        這些實體中存放著我們需要訪問的資源，資源代表著具體的車輛數(shù)據(jù)。SOVD API 提供了豐富的資源集合，包括 configurations、bulk-data、data、faults 等等，涵蓋了汽車數(shù)據(jù)的方方面面。

        基于上面的知識，就可以嘗試進行數(shù)據(jù)訪問了。例如，若需獲取車輛后窗的狀態(tài)，可以發(fā)送以下GET請求：

GET {base_uri}/apps/WindowControl/data/RearWindows HTTP/1.1

SOVD API

        當診斷對象為HPC控制器時，我們能夠通過SOVD協(xié)議中定義的標準API直接訪問相關數(shù)據(jù)。這些API不僅規(guī)范了對不同類型資源的訪問方式，還將復雜的車輛數(shù)據(jù)和操作進行了標準化處理，為開發(fā)者和使用者提供了一套高效且完整的解決方案。

        以下是一些場景下的SOVD API的使用示例：

        · 當需要檢查某個電子控制單元（ECU）的狀態(tài)時，SOVD API可以通過GET /{entity-path}/data/{data-id}直接獲取相關數(shù)據(jù)；

        · 如果要清除故障碼，只需調(diào)用DELETE /{entity-path}/faults/{fault-code}即可完成操作；

        · 當車輛需要軟件更新時，API提供了從準備（PUT /updates/{update-package-id}/prepare）到執(zhí)行（PUT /updates/{update-package-id}/execute）的支持，以保障系統(tǒng)持續(xù)處于更新后的狀態(tài)。

        此外，SOVD API還支持批量數(shù)據(jù)處理（如日志文件管理）、鎖定機制避免資源沖突，以及靈活的配置和模式切換功能等等。無論是讀取車速信息、控制車窗操作，還是清除故障碼，都可以通過這些標準API以更加直觀的方式實現(xiàn)。

SOVD與UDS

        當診斷對象為傳統(tǒng)ECU時，我們需要一個網(wǎng)關進行SOVD-UDS的路由轉換。在SOVD規(guī)范中，已經(jīng)對常見的 UDS 服務與SOVD 映射關系進行了描述：

        這種UDS-SOVD的適配方案，將傳統(tǒng)的UDS診斷協(xié)議與現(xiàn)代SOVD架構相結合，為車輛診斷帶來了更高的靈活性和可擴展性。通過RESTful接口，診斷工具能夠以更直觀、更標準化的方式訪問和操作車輛數(shù)據(jù)，同時完整保留了UDS的核心功能。這種設計體現(xiàn)了SOVD的良好適應性，同時也降低了使用SOVD作為診斷協(xié)議的門檻。

SOVD的發(fā)展與應用

        盡管ASAM提出的SOVD協(xié)議為汽車診斷帶來了更靈活、更高效的解決方案，但其在實際應用中仍面臨一定挑戰(zhàn)，例如技術細節(jié)的實現(xiàn)等。然而，SOVD的標準化進程的也在穩(wěn)步推進，ISO/AWI 17978-1（ISO定義的SOVD協(xié)議的第一部分）預計將在今年發(fā)布，這無疑將為SOVD的廣泛應用奠定更堅實的基礎。

        作為國內(nèi)SOVD技術的早期探索者，經(jīng)緯恒潤已成功助力多家OEM完成SOVD協(xié)議的開發(fā)與測試工作。公司構建了完整的SOVD系統(tǒng)架構設計方法論，涵蓋需求規(guī)范制定、服務數(shù)據(jù)庫構建以及技術培訓體系，為客戶提供全方位的技術支持。同時，經(jīng)緯恒潤具備SOVD協(xié)議棧開發(fā)能力，可支持協(xié)議的開發(fā)與集成，并建立了完善的SOVD測試規(guī)范體系，提供配套的自動化測試腳本和專業(yè)化實施服務。通過一致性檢查、性能測試及安全檢測等多維度驗證，可確保SOVD系統(tǒng)在復雜車載環(huán)境中的可靠性與穩(wěn)定性。

        隨著SOVD技術的不斷演進，經(jīng)緯恒潤將持續(xù)發(fā)揮自身優(yōu)勢，深入挖掘協(xié)議的潛在價值，助力客戶在汽車生產(chǎn)與應用中進一步釋放SOVD協(xié)議的潛力。我們期待，SOVD協(xié)議將為汽車行業(yè)注入更多創(chuàng)新動力與可能性，推動汽車診斷技術實現(xiàn)新的突破與發(fā)展。

了解更多

        請致電 010-64840808轉6116 或發(fā)郵件至market_dept@hirain.com（聯(lián)系時請說明來自EEPW）