一直想寫乙個關於uds學習的系列文章，卻一直沒有動筆，一來是由於覺得自己學得還不夠透徹，二來想一開始就把文章寫得很完美，然而事實上真正要做到對協議非常透徹得話，又談何容易，協議是死的，人是活的，對於實際專案的不同，可能對協議的實現也是很不相同的，之前有做過這方面的工作，奈何一直覺得自己沒有深入的去理解學習，現在開始真正的著手寫關於uds診斷寫的乙個系列文章，一方面自己重新認真的去理解學習uds協議，另一方面也希望幫助到剛開始學習這方面知識的朋友。文章中如果有表述不正確的地方或者有更好的建議。
可能對於剛接觸uds的朋友，並不理解到底什麼是汽車診斷，當初我剛開始聽到這個詞語的時候，也是一樣的感覺。uds全稱(unified diagnostic services)，標準號為iso14229，所以平常我們說iso14229或者uds其實指的是同乙個東西。
那麼我們為什麼需要這樣乙個東西的，這個東西在實際的產品中到底起著哪些作用？
通過iso14229-1可以找到如下的一張圖：
這張圖非常清晰的展示了iso14229協議的層次，我們從底層往上層開始看，這裡以can為例子，這裡我們只關注紅框部分，最左邊的docan中，最下面的物理層和資料鏈路層是can協議規範，對於uds，一般我們需要去寫的是從傳輸層（transport/network）開始，這裡又牽涉到傳輸層協議iso15765，這裡先不深究，傳輸層主要就是用於組包分包，因為can協議一幀最多隻能夠傳輸8個位元組（fd 64個位元組），一些超過這個數量的訊息，就需要通過tp層將多個can幀組成乙個資料報，然後傳給uds使用，或者將uds的資料拆成多個can幀傳送。後續我們再單獨說tp層，總之這裡就記住tp是用於can訊息幀組包拆包的。
隨後的應用層就是uds中最主要的部分，這裡就包含了所有uds多定義的服務。至此我們可以跟著資料流的方向去理解整個uds協議。當診斷儀傳送乙個命令如22h查詢ecu的版本號，ecu的can收到訊息後，根據can id得知這個是資料uds的訊息，便將訊息交給了tp層，tp層處理後，將資料交給uds層，uds得知這是乙個22h服務，同時此時許可權也滿足，便將訊息給了22h服務去處理，22h服務根據定義將ecu版本號再根據剛剛的路線將資料返回給診斷儀，經過這樣乙個過程，診斷儀得到了ecu的版本號。當然乙個簡化的診斷過程。
uds其實就是一套協議，用於規定診斷儀與ecu之間通訊的協議。診斷儀通過所規定的命令，去訪問/修改ecu的一些資料。
UDS診斷入門學習資料
uds診斷入門學習資料學習資料 1.統一診斷服務 unified diagnostic services uds 一 2.統一診斷服務 unified diagnostic services uds 二 3.統一診斷服務 unified diagnostic services uds 三 4.統一診...
基於CAN匯流排的汽車診斷協議（包括UDS診斷）
10 02 10 03模式切換，s3 client開始診斷報文超時計時 3e80保持會話 cantp層 client 發36首幀10，server回流控30 08，client發8幀連續幀20 2f 500k，1ms發4幀 flowcontrol第一位元組的高4bit為0011，低4bit為fs，即...
01 hadoop入門簡介
1.資料體量大。中小型公司的資料量在tb級別，大型公司的資料量是pb級別 京東每天的日誌量達到2.5pb 3pb之間 2.資料的種類和 多樣化，致使處理手段越來越多樣化 3.資料增長越來越快。網際網路的出現及發展使得資訊傳播速度越來越快 4.資料的價值密度越來越低。價值密度是所需要的資訊 資訊的總量...