新的車載診斷架構(gòu)——面向服務(wù)的汽車診斷

診斷功能是車輛控制器自屬的功能，通過診斷功能可以快速獲取車輛控制器狀態(tài)信息（數(shù)據(jù)信息、DTC故障信息）、Software Update等，它的模型如下：

作為應(yīng)激式響應(yīng)，ECU收到診斷請求后才會給與對應(yīng)的響應(yīng)。

隨著HPC（高性能計算機）的引入，以及未來車輛中越來越多的車載系統(tǒng)以軟件為基礎(chǔ)，診斷必不可免面臨著新的挑戰(zhàn)。具有異構(gòu)操作系統(tǒng)和大量并行進程的強大計算系統(tǒng)需要新的診斷功能（驅(qū)動力）。

與軟件和汽車診斷相關(guān)的變更的頻率顯著提高（這也是敏捷開發(fā)逐漸成為車載軟件開發(fā)必不可少的一種模型的原因），需要采用新的數(shù)據(jù)管理方法。

在這種情況下，面向服務(wù)的車載診斷（SOVD）項目于2019年在ASAM啟動，旨在創(chuàng)建簡單的新一代診斷接口，同時訪問傳統(tǒng)ECU和以軟件為基礎(chǔ)的新系統(tǒng)，實現(xiàn)遠程、近端和車載診斷場景的統(tǒng)一訪問。

“

車載診斷數(shù)據(jù)庫ODX最初也是ASAM先提出并進行內(nèi)容定義的，后續(xù)ISO組織納入了ISO協(xié)議簇中（ISO22901）

”

由于HPC（大算力、實時性）的引入，以及汽車中越來越多的車載系統(tǒng)以軟件為基礎(chǔ)，診斷在以往的模型中逐漸不適應(yīng)新的模式。

對HPC和應(yīng)用程序進行診斷所需的數(shù)據(jù)很難與ODX（開放診斷交換格式）和UDS（統(tǒng)一診斷服務(wù)）的靜態(tài)結(jié)構(gòu)結(jié)合起來。本機應(yīng)用程序還使用其他接口或數(shù)據(jù)格式，這些接口或格式很難映射到基于UDS的字節(jié)序列中。因為新的數(shù)據(jù)內(nèi)容需要在診斷需求規(guī)范中先定義出來，并體現(xiàn)在診斷數(shù)據(jù)庫中，作為代碼配置工具的輸入數(shù)據(jù)內(nèi)容。

基于UDS的診斷需要為通信提供離線的靜態(tài)描述，通常采用ODX格式。然而，越來越多的基于軟件的架構(gòu)的主要目標(biāo)是將新的軟件和功能快速靈活地“上車”。實際上，為軟件的每個版本都提供適當(dāng)?shù)脑\斷描述幾乎是不可能的。

在UDS中，診斷尋址基于靜態(tài)標(biāo)識符，不夠靈活。通信矩陣在車輛項目前期已經(jīng)定義完畢，中途的更改很復(fù)雜，因此很少進行更改。這與快速將新的軟件組件引入汽車的需求形成對比。

即使在汽車中引入中央計算機系統(tǒng)后，仍有相當(dāng)數(shù)量的傳統(tǒng)ECU構(gòu)成基于軟件的功能的基石。出于需求和資源的考慮，傳統(tǒng)ECU目前基于熟悉的軟件平臺（如AUTOSAR Classic），未來將繼續(xù)如此。傳統(tǒng)ECU采用基于UDS的診斷。因此，必須將這些診斷無縫集成到SOVD中。

在新的診斷框架中，主要目的如下：

-> 同時用于診斷和軟件更新的統(tǒng)一API（應(yīng)用程序編程接口）

-> 同時用于新系統(tǒng)和傳統(tǒng)傳感器/執(zhí)行器系統(tǒng)的統(tǒng)一API

-> 使用場景：近端（通過有線/短距離無線通信連接到汽車），車載（隨車行駛）和遠程（離汽車很遠）

-> 自我描述API允許在沒有外部描述文件的情況下進行診斷。然而，未來仍需要一些外部描述，例如能夠創(chuàng)建交叉變量測試序列

-> 應(yīng)該選擇并組合合適的現(xiàn)有技術(shù)，避免發(fā)明一種全新的技術(shù)

汽車中各種各樣的軟件組件和（帶有處理器/控制器的）設(shè)備不僅有助于功能，也有助于診斷。在每個案例中，診斷和軟件更新請求都會轉(zhuǎn)發(fā)給相應(yīng)的進程代理。

抽象而言，診斷請求是對特定資源的操作，例如：

-> 讀取單個或一系列的測量值和系統(tǒng)參數(shù)

-> 讀取事件和故障存儲

-> 更改參數(shù)

-> 啟動特殊診斷功能

-> 控制/訪問執(zhí)行器和傳感器

此外，請求可以檢索具體資源（硬件或軟件部分）的自我描述（“能力描述”）。可以請求的診斷范圍可能取決于請求者的角色或授權(quán)。自我描述包括當(dāng)前角色可以請求的所有診斷范圍。

如果請求被定向到支持UDS診斷的ECU，則必須將SOVD請求轉(zhuǎn)換為UDS診斷，響應(yīng)同樣需要轉(zhuǎn)換。將SOVD轉(zhuǎn)換為UDS（反之亦然）稱為“傳統(tǒng)診斷適配器”。

對于請求者來說，請求是指向高性能計算機還是支持UDS的傳統(tǒng)ECU應(yīng)該沒有區(qū)別。傳統(tǒng)診斷適配器允許請求者使用SOVD API，并且只處理符號值和數(shù)據(jù)。

ASAM SOVD的目標(biāo)是為新系統(tǒng)和傳統(tǒng)傳感器/執(zhí)行器的診斷制定統(tǒng)一的API。

開發(fā)ASAM SOVD的一個重要前提是使用適當(dāng)?shù)募夹g(shù)，而不是發(fā)明（或重新發(fā)明）新技術(shù)。SOVD API基于http/REST方法。

ASAM SOVD API支持查詢自我描述，以避免依賴外部數(shù)據(jù)規(guī)范。盡管如此，仍有離線文檔和規(guī)范的相關(guān)機制，以支持開發(fā)、生產(chǎn)和售后過程。

ASAM SOVD關(guān)注接口（API）的定義。在汽車上實施SOVD不是ASAM項目的主題。然而，AUTOSAR已經(jīng)開展如何實施SOVD的活動(2022版最新AUTOSAR規(guī)范中已經(jīng)對SOVD做了規(guī)范定義)。

2022年6月底，ASAM SOVD 1.0.0版本正式發(fā)布。用于應(yīng)對智能網(wǎng)聯(lián)汽車時代井噴的軟件診斷需求，SOVD如何應(yīng)對呢？

ASAM SOVD (Service-Oriented Vehicle Diagnostics，面向服務(wù)的車輛診斷) 定義了一個與基于軟件的車輛進行診斷和通信的接口API。SOVD是一個靈活的標(biāo)準(zhǔn)，提供了統(tǒng)一的訪問HPC (High Performance Computing，高性能計算機) 及其相關(guān)應(yīng)用的診斷內(nèi)容，以及經(jīng)典的ECU等。

隨著自動駕駛技術(shù)的發(fā)展，車輛配置變得越來越復(fù)雜，車載軟件也在迅速增長：基于高性能計算、多操作系統(tǒng)、不同應(yīng)用程序及其依賴關(guān)系的新架構(gòu)也給診斷工作帶來了重大挑戰(zhàn)。診斷的重點從識別硬件錯誤逐漸擴展到分析軟件問題，因此帶來了巨大的挑戰(zhàn)。因為車輛的內(nèi)容是動態(tài)變化的，同時當(dāng)診斷通信被用于控制車輛復(fù)雜的更新過程時，診斷任務(wù)的范圍也急劇增加。

目前的診斷以ECU為核心，嚴重依賴于UDS (Unified Diagnostic Services，統(tǒng)一診斷服務(wù)) 協(xié)議。UDS是一種靜態(tài)的診斷方法，無法應(yīng)用于動態(tài)的軟件診斷任務(wù)。因此，為HPC診斷需求擴展的UDS協(xié)議將不夠靈活，無法滿足必要的軟件分析需求。

這就是ASAM開發(fā)與制定SOVD的原因。該標(biāo)準(zhǔn)旨在為所有診斷任務(wù)以及軟件更新（跨車輛、車型）提供一個API。SOVD是具有一致性的方法，可用于全新系統(tǒng)，也可用于傳統(tǒng)的傳感器/執(zhí)行器系統(tǒng)，同時，ASAM SOVD可用于近程、遠程和車載三種應(yīng)用場景。SOVD是一個自描述API，還支持無需外部描述文件的診斷，有別于當(dāng)前的主流技術(shù)。

ASAM SOVD的開發(fā)旨在保持現(xiàn)有的程序、技術(shù)和方法的前提下，滿足車載軟件診斷的相關(guān)需求和挑戰(zhàn)。因此，ASAM SOVD既涵蓋了傳統(tǒng)的用例(數(shù)據(jù)訪問、故障信息、內(nèi)部軟件功能控制等)，也涵蓋了與HPC相關(guān)的診斷用例(車載軟件更新、日志記錄、跟蹤、系統(tǒng)信息訪問、內(nèi)容動態(tài)發(fā)現(xiàn)等)。另一方面，SOVD并非為了取代廣泛使用的技術(shù)，如UDS協(xié)議，而是與其共存，同時增強診斷通信功能，更好地支持新技術(shù)的發(fā)展與應(yīng)用。

ASAM SOVD的主要內(nèi)容與更新包括以下部分：

-> SOVD為診斷提供了新的接口API；

-> 適用于遠程、近程和車載應(yīng)用場景；

-> 支持最先進的IT技術(shù)(HTTP, REST, JSON, OAuth)；

-> 診斷可以獨立于診斷數(shù)據(jù)描述文件；

-> 整個計算過程被封裝，使無狀態(tài)訪問成為可能；

-> 客戶端實現(xiàn)不需要汽車特定的堆棧。

ASAM SOVD總體特性包括：

-> 可覆蓋傳統(tǒng)診斷用例：

-> 數(shù)據(jù)訪問（Data Access）；

-> 故障信息（Fault Information）；

-> 控制內(nèi)部軟件功能（Internal Software-functions）。

可覆蓋高性能計算相關(guān)的診斷用例：

-> 車輛軟件升級（Software update）；

-> 記錄（Logging）；

-> 訪問系統(tǒng)信息（Access to system information）；

-> 動態(tài)內(nèi)容發(fā)現(xiàn)（Dynamic discovery of content）；

在能力檢測方面，可進行相關(guān)實體與資源的檢查與發(fā)現(xiàn)：

-> 發(fā)現(xiàn)包含的實體；

-> 查詢實體的子實體；

-> 查詢實體相關(guān)的其他實體；

-> 查詢實體功能；

-> 代表實體區(qū)域的拓撲視圖，能夠代表面向領(lǐng)域和面向區(qū)域的體系結(jié)構(gòu)

訪問功能描述內(nèi)容：

-> 查詢在線能力描述；

-> 查詢模式信息，用于內(nèi)容處理