新的車(chē)載診斷架構(gòu)——面向服務(wù)的汽車(chē)診斷診斷功能是車(chē)輛控制器自屬的功能，通過(guò)診斷功能可以快速獲取車(chē)輛控制器狀態(tài)信息（數(shù)據(jù)信息、DTC故障信息）、Software Update等，它的模型如下：作為應(yīng)激式響應(yīng)，ECU收到診斷請(qǐng)求后才會(huì)給與對(duì)應(yīng)的響應(yīng)。隨著HPC（高性能計(jì)算機(jī)）的引入，以及未來(lái)車(chē)輛中越來(lái)越多的車(chē)載系統(tǒng)以軟件為基礎(chǔ)，診斷必不可免面臨著新的挑戰(zhàn)。具有異構(gòu)操作系統(tǒng)和大量并行進(jìn)程的強(qiáng)大計(jì)算系統(tǒng)需要新的診斷功能（驅(qū)動(dòng)力）。與軟件和汽車(chē)診斷相關(guān)的變更的頻率顯著提高（這也是敏捷開(kāi)發(fā)逐漸成為車(chē)載軟件開(kāi)發(fā)必不可少的一種模型的原因），需要采用新的數(shù)據(jù)管理方法。在這種情況下，面向服務(wù)的車(chē)載診斷（SOVD）項(xiàng)目于2019年在ASAM啟動(dòng)，旨在創(chuàng)建簡(jiǎn)單的新一代診斷接口，同時(shí)訪問(wèn)傳統(tǒng)ECU和以軟件為基礎(chǔ)的新系統(tǒng)，實(shí)現(xiàn)遠(yuǎn)程、近端和車(chē)載診斷場(chǎng)景的統(tǒng)一訪問(wèn)。“ 由于HPC（大算力、實(shí)時(shí)性）的引入，以及汽車(chē)中越來(lái)越多的車(chē)載系統(tǒng)以軟件為基礎(chǔ)，診斷在以往的模型中逐漸不適應(yīng)新的模式。對(duì)HPC和應(yīng)用程序進(jìn)行診斷所需的數(shù)據(jù)很難與ODX（開(kāi)放診斷交換格式）和UDS（統(tǒng)一診斷服務(wù)）的靜態(tài)結(jié)構(gòu)結(jié)合起來(lái)。本機(jī)應(yīng)用程序還使用其他接口或數(shù)據(jù)格式，這些接口或格式很難映射到基于UDS的字節(jié)序列中。因?yàn)樾碌臄?shù)據(jù)內(nèi)容需要在診斷需求規(guī)范中先定義出來(lái)，并體現(xiàn)在診斷數(shù)據(jù)庫(kù)中，作為代碼配置工具的輸入數(shù)據(jù)內(nèi)容。基于UDS的診斷需要為通信提供離線的靜態(tài)描述，通常采用ODX格式。然而，越來(lái)越多的基于軟件的架構(gòu)的主要目標(biāo)是將新的軟件和功能快速靈活地“上車(chē)”。實(shí)際上，為軟件的每個(gè)版本都提供適當(dāng)?shù)脑\斷描述幾乎是不可能的。在UDS中，診斷尋址基于靜態(tài)標(biāo)識(shí)符，不夠靈活。通信矩陣在車(chē)輛項(xiàng)目前期已經(jīng)定義完畢，中途的更改很復(fù)雜，因此很少進(jìn)行更改。這與快速將新的軟件組件引入汽車(chē)的需求形成對(duì)比。即使在汽車(chē)中引入中央計(jì)算機(jī)系統(tǒng)后，仍有相當(dāng)數(shù)量的傳統(tǒng)ECU構(gòu)成基于軟件的功能的基石。出于需求和資源的考慮，傳統(tǒng)ECU目前基于熟悉的軟件平臺(tái)（如AUTOSAR Classic），未來(lái)將繼續(xù)如此。傳統(tǒng)ECU采用基于UDS的診斷。因此，必須將這些診斷無(wú)縫集成到SOVD中。在新的診斷框架中，主要目的如下：-> 同時(shí)用于診斷和軟件更新的統(tǒng)一API（應(yīng)用程序編程接口）-> 同時(shí)用于新系統(tǒng)和傳統(tǒng)傳感器/執(zhí)行器系統(tǒng)的統(tǒng)一API-> 使用場(chǎng)景：近端（通過(guò)有線/短距離無(wú)線通信連接到汽車(chē)），車(chē)載（隨車(chē)行駛）和遠(yuǎn)程（離汽車(chē)很遠(yuǎn)）-> 自我描述API允許在沒(méi)有外部描述文件的情況下進(jìn)行診斷。然而，未來(lái)仍需要一些外部描述，例如能夠創(chuàng)建交叉變量測(cè)試序列-> 應(yīng)該選擇并組合合適的現(xiàn)有技術(shù)，避免發(fā)明一種全新的技術(shù)汽車(chē)中各種各樣的軟件組件和（帶有處理器/控制器的）設(shè)備不僅有助于功能，也有助于診斷。在每個(gè)案例中，診斷和軟件更新請(qǐng)求都會(huì)轉(zhuǎn)發(fā)給相應(yīng)的進(jìn)程代理。抽象而言，診斷請(qǐng)求是對(duì)特定資源的操作，例如：-> 讀取單個(gè)或一系列的測(cè)量值和系統(tǒng)參數(shù)-> 讀取事件和故障存儲(chǔ)-> 更改參數(shù)-> 啟動(dòng)特殊診斷功能-> 控制/訪問(wèn)執(zhí)行器和傳感器此外，請(qǐng)求可以檢索具體資源（硬件或軟件部分）的自我描述（“能力描述”）。可以請(qǐng)求的診斷范圍可能取決于請(qǐng)求者的角色或授權(quán)。自我描述包括當(dāng)前角色可以請(qǐng)求的所有診斷范圍。如果請(qǐng)求被定向到支持UDS診斷的ECU，則必須將SOVD請(qǐng)求轉(zhuǎn)換為UDS診斷，響應(yīng)同樣需要轉(zhuǎn)換。將SOVD轉(zhuǎn)換為UDS（反之亦然）稱為“傳統(tǒng)診斷適配器”。對(duì)于請(qǐng)求者來(lái)說(shuō)，請(qǐng)求是指向高性能計(jì)算機(jī)還是支持UDS的傳統(tǒng)ECU應(yīng)該沒(méi)有區(qū)別。傳統(tǒng)診斷適配器允許請(qǐng)求者使用SOVD API，并且只處理符號(hào)值和數(shù)據(jù)。ASAM SOVD的目標(biāo)是為新系統(tǒng)和傳統(tǒng)傳感器/執(zhí)行器的診斷制定統(tǒng)一的API。開(kāi)發(fā)ASAM SOVD的一個(gè)重要前提是使用適當(dāng)?shù)募夹g(shù)，而不是發(fā)明（或重新發(fā)明）新技術(shù)。SOVD API基于http/REST方法。ASAM SOVD API支持查詢自我描述，以避免依賴外部數(shù)據(jù)規(guī)范。盡管如此，仍有離線文檔和規(guī)范的相關(guān)機(jī)制，以支持開(kāi)發(fā)、生產(chǎn)和售后過(guò)程。ASAM SOVD關(guān)注接口（API）的定義。在汽車(chē)上實(shí)施SOVD不是ASAM項(xiàng)目的主題。然而，AUTOSAR已經(jīng)開(kāi)展如何實(shí)施SOVD的活動(dòng)(2022版最新AUTOSAR規(guī)范中已經(jīng)對(duì)SOVD做了規(guī)范定義)。2022年6月底，ASAM SOVD 1.0.0版本正式發(fā)布。用于應(yīng)對(duì)智能網(wǎng)聯(lián)汽車(chē)時(shí)代井噴的軟件診斷需求，SOVD如何應(yīng)對(duì)呢？ASAM SOVD (Service-Oriented Vehicle Diagnostics，面向服務(wù)的車(chē)輛診斷) 定義了一個(gè)與基于軟件的車(chē)輛進(jìn)行診斷和通信的接口API。SOVD是一個(gè)靈活的標(biāo)準(zhǔn)，提供了統(tǒng)一的訪問(wèn)HPC (High Performance Computing，高性能計(jì)算機(jī)) 及其相關(guān)應(yīng)用的診斷內(nèi)容，以及經(jīng)典的ECU等。隨著自動(dòng)駕駛技術(shù)的發(fā)展，車(chē)輛配置變得越來(lái)越復(fù)雜，車(chē)載軟件也在迅速增長(zhǎng)：基于高性能計(jì)算、多操作系統(tǒng)、不同應(yīng)用程序及其依賴關(guān)系的新架構(gòu)也給診斷工作帶來(lái)了重大挑戰(zhàn)。診斷的重點(diǎn)從識(shí)別硬件錯(cuò)誤逐漸擴(kuò)展到分析軟件問(wèn)題，因此帶來(lái)了巨大的挑戰(zhàn)。因?yàn)檐?chē)輛的內(nèi)容是動(dòng)態(tài)變化的，同時(shí)當(dāng)診斷通信被用于控制車(chē)輛復(fù)雜的更新過(guò)程時(shí)，診斷任務(wù)的范圍也急劇增加。目前的診斷以ECU為核心，嚴(yán)重依賴于UDS (Unified Diagnostic Services，統(tǒng)一診斷服務(wù)) 協(xié)議。UDS是一種靜態(tài)的診斷方法，無(wú)法應(yīng)用于動(dòng)態(tài)的軟件診斷任務(wù)。因此，為HPC診斷需求擴(kuò)展的UDS協(xié)議將不夠靈活，無(wú)法滿足必要的軟件分析需求。這就是ASAM開(kāi)發(fā)與制定SOVD的原因。該標(biāo)準(zhǔn)旨在為所有診斷任務(wù)以及軟件更新（跨車(chē)輛、車(chē)型）提供一個(gè)API。SOVD是具有一致性的方法，可用于全新系統(tǒng)，也可用于傳統(tǒng)的傳感器/執(zhí)行器系統(tǒng)，同時(shí)，ASAM SOVD可用于近程、遠(yuǎn)程和車(chē)載三種應(yīng)用場(chǎng)景。SOVD是一個(gè)自描述API，還支持無(wú)需外部描述文件的診斷，有別于當(dāng)前的主流技術(shù)。ASAM SOVD的開(kāi)發(fā)旨在保持現(xiàn)有的程序、技術(shù)和方法的前提下，滿足車(chē)載軟件診斷的相關(guān)需求和挑戰(zhàn)。因此，ASAM SOVD既涵蓋了傳統(tǒng)的用例(數(shù)據(jù)訪問(wèn)、故障信息、內(nèi)部軟件功能控制等)，也涵蓋了與HPC相關(guān)的診斷用例(車(chē)載軟件更新、日志記錄、跟蹤、系統(tǒng)信息訪問(wèn)、內(nèi)容動(dòng)態(tài)發(fā)現(xiàn)等)。另一方面，SOVD并非為了取代廣泛使用的技術(shù)，如UDS協(xié)議，而是與其共存，同時(shí)增強(qiáng)診斷通信功能，更好地支持新技術(shù)的發(fā)展與應(yīng)用。ASAM SOVD的主要內(nèi)容與更新包括以下部分：-> SOVD為診斷提供了新的接口API；-> 適用于遠(yuǎn)程、近程和車(chē)載應(yīng)用場(chǎng)景；-> 支持最先進(jìn)的IT技術(shù)(HTTP, REST, JSON, OAuth)；-> 診斷可以獨(dú)立于診斷數(shù)據(jù)描述文件；-> 整個(gè)計(jì)算過(guò)程被封裝，使無(wú)狀態(tài)訪問(wèn)成為可能；-> 客戶端實(shí)現(xiàn)不需要汽車(chē)特定的堆棧。ASAM SOVD總體特性包括：-> 可覆蓋傳統(tǒng)診斷用例：-> 數(shù)據(jù)訪問(wèn)（Data Access）；-> 故障信息（Fault Information）；-> 控制內(nèi)部軟件功能（Internal Software-functions）。可覆蓋高性能計(jì)算相關(guān)的診斷用例：-> 車(chē)輛軟件升級(jí)（Software update）；-> 記錄（Logging）；-> 訪問(wèn)系統(tǒng)信息（Access to system information）；-> 動(dòng)態(tài)內(nèi)容發(fā)現(xiàn)（Dynamic discovery of content）；在能力檢測(cè)方面，可進(jìn)行相關(guān)實(shí)體與資源的檢查與發(fā)現(xiàn)：-> 發(fā)現(xiàn)包含的實(shí)體；-> 查詢實(shí)體的子實(shí)體；-> 查詢實(shí)體相關(guān)的其他實(shí)體；-> 查詢實(shí)體功能；-> 代表實(shí)體區(qū)域的拓?fù)湟晥D，能夠代表面向領(lǐng)域和面向區(qū)域的體系結(jié)構(gòu)訪問(wèn)功能描述內(nèi)容：-> 查詢?cè)诰€能力描述；-> 查詢模式信息，用于內(nèi)容處理 |
|
|
來(lái)自： 車(chē)載診斷技術(shù) > 《待分類》
