基于IIC協議的汽車多聯屏故障診斷技術

關鍵詞：汽車診斷；故障診斷；汽車多聯屏；集成電路總線（IIC）

0 前言

汽車診斷是指通過檢測電子控制單元（ECU）的傳感器、控制器等電子元件的信號［1］，按照汽車廠商規定的診斷策略來判斷系統是否存在故障，并且將故障以故障碼的形式記錄到ECU 中存儲，以便后續可以通過診斷儀來讀取。

本文以汽車多聯屏的診斷技術作為切入點，介紹了汽車診斷、汽車多聯屏、集成電路總線（IIC）通信協議的相關概念，闡述診斷模塊的搭建框架及與其他模塊之間的通信，并對所搭建的診斷模塊進行系統測試，模塊測試成功后進行集成測試，最后進行整車測試。

1 汽車診斷及多聯屏的概念

1. 1 診斷

診斷的概念最初是從醫學角度提出的，即對人們的精神和體質狀態作出判斷。從汽車的角度來看，汽車診斷也就是從全局出發對汽車狀態作出判斷，幫助汽車發現問題，準確定位汽車上發生問題的位置和原因。通過診斷提供的信息找到出現問題的ECU 模塊，可以在汽車出現故障時避免對整車進行拆卸。目前，汽車診斷根據功能的復雜程度可以分為四大類，即人工經驗診斷、簡單儀器診斷、精密儀器診斷和人工智能診斷。市場上使用較多的是人工經驗診斷結合精密儀器診斷技術。

汽車診斷是一種通信過程，是基于開放式系統互連（OSI）七層協議實現的，如圖1 所示。本系統中所提的診斷技術參考統一診斷服務（UDS）協議［2］，處于OSI 七層協議的應用層和會話層［3］。

1. 2 診斷服務

診斷服務是基于UDS 協議開發的，UDS 協議是診斷服務的標準化規范，由《道路車輛統一診斷服務（UDS）》（ISO 14229—2013）定義。UDS 是一種客戶端/服務器端的通信服務，即測試者向ECU 發送診斷請求，ECU 響應對應的診斷請求。

UDS 協議定義了5 種診斷服務內容，可細分為25 個服務標志號（ID）。UDS 協議僅僅為診斷服務提供基本框架，主機廠和零部件供應商可以根據實際開發的具體情況來選擇實現其中的一部分服務或是自定義給出一些僅供內部使用的私有化診斷服務。常用的汽車診斷服務見表1。

1. 3 汽車多聯屏

汽車多聯屏是一種近年來興起的汽車顯示器結構，主要是在汽車上安裝多個顯示屏，而這些顯示屏是由同一個主機控制的。多聯屏也被部分汽車零部件開發商稱之為智能飛屏或車機聯動功能屏。

汽車多聯屏的原理是利用市面上較大尺寸的高清數字儀表屏（多為10.25 in（26.035 cm）或12.30 in（31.242 cm）），結合更大尺寸的全高清集娛樂與智能化功能一體的中控大屏，搭載于主機盒上。儀表屏除了有顯示速度表、燃油表、轉速表、水溫表等基礎功能外，還設置了全新的用戶界面（UI）圖，彩色圖像顯示，視覺效果煥然一新，儀表屏上可以顯示導航地圖、行車、停車等多種場景，營造出時尚愉悅的駕乘氛圍，塑造了更高的科技感。較為完善的汽車多聯屏技術可以將導航、通話、娛樂等功能直接從中控大屏手動拖動至儀表屏顯示，加大了安全保障，使得駕駛人員的視線始終在前方，不用分心去看中控大屏，汽車多聯屏給駕駛人員帶來了更加人性化、科技感的視覺體驗效果。

2 IIC 通信技術

針對IIC 通信協議，IIC 在進行數據傳送時，數據在時鐘線結構化控制語言（SCL）的上升沿到來之前就需要準備完畢，并且必須在下降沿到來之前保持穩定［4］。時鐘信號為高電平期間，數據線上的數據必須保持穩定，穩定在高電平或者低電平的狀態，不允許隨意變化；而只有當時鐘信號為低電平期間，數據線上的數據狀態才允許變化，可以由高電平變為低電平，也可以由低電平切換為高電平。

發送器每發送1 個字節信號，接收器就反饋1 個應答信號。如果反饋的應答信號為低電平，則規定此應答為有效應答（ACK），表示接收器已經成功地接受了該字節傳輸的數據；而當反饋的應答信號為高電平時，規定此應答為非有效應答（NACK），表示接收器沒有成功接收該字節。

對于通過IIC 進行的數據傳輸［5］，傳輸的每一個字節首先必須要保證是8 bit。數據傳送時，先傳送最高位，每一個被傳送的字節后面都必須跟隨1 位應答位（即每一幀數據有9 bit）；在IIC 上傳送的每一位數據都有一個時鐘脈沖相對應（或同步控制），即在SCL 串行時鐘的配合下，在串行數據（SDA）上逐位地串行傳送每一位數據。數據位的傳輸邊沿觸發。

3 系統整體架構設計

汽車多聯屏診斷模塊主要分為需求分析、策略定義、架構設計、代碼編寫與測試等環節，具體開發流程如圖2 所示。

3. 1 系統需求分析

傳統汽車儀表診斷功能的開發都是基于控制器域網（CAN）信號的，但對于汽車多聯屏來說，由于它是由主機盒和多個顯示屏連接的，而一般的主機廠為了節省成本和加快開發效率，會將屏和主機盒的研發工作分給不同的供應商，主機盒和各屏之間的連接基本都采用IIC 通信協議，因此在這種儀表屏上的診斷開發也基于IIC 通信協議。

診斷可分為在線診斷和離線診斷兩大類，在線診斷指在汽車運行過程中對汽車各個ECU 模塊的實時監控，如有問題直接以報警的方式提示用戶；離線診斷則是指故障信息先記錄到汽車ECU 的不可擦除的只讀存儲器（ROM）中，后續診斷儀通過車載自診斷系統（OBD）接口連接到汽車，讀出故障信息。無論是在線診斷還是離線診斷都是用來對整車的故障狀態進行記錄，方便后續的分析。

需求分析階段需要與客戶協商具體的服務內容，以ISO 14229—2013 標準作為基礎，與客戶進行交流定義。服務的大框架確定后，還需要進行詳細的需求分析。不同的主機廠對于DTC 的代碼定義不同，因此在需求分析階段必須給出具體的要求，才可以進行后續的開發，根據需求和定義的策略進行診斷模塊代碼的撰寫和測試。模塊只有經過測試并符合要求后才可以實際應用到整車中。

3. 2 診斷模塊框架搭建

診斷功能代碼實現部分可分為兩大模塊，即服務管理和DTC 記錄。服務管理主要是針對客戶需要的相關服務進行設計，包括會話層的切換、存儲信息的讀取等。DTC 記錄主要是記錄故障碼中需要存儲的信息，以固定的格式將信息存儲到不可擦除的ROM 中。服務管理具體包括會話層的切換，ECU 安全訪問功能確認，數據和內存的讀取和存儲操作，輸入和輸出硬件端口的信息，以及故障碼和讀取和清除等。DTC 記錄具體包括記錄故障發生的具體時間、發生的次數，以及在故障發生到讀取故障碼的過程中是否恢復等。DTC 記錄數據后將數據與服務管理模塊進行交互，主機盒可以通過發出指令來讀取出DTC，同樣也可以通過指令清除DTC。

當診斷的模塊大框架搭建完畢后，需要進入具體的代碼編寫階段，代碼撰寫同樣也是分為2 個模塊，每個模塊按照定義的需求完成指定的功能，具體模塊之間的調用如圖3 所示。模塊搭建完畢后，需要使用IIC 通信模塊提供的接口進行數據的發送和接收，而診斷也會提供相應的接口供其他模塊調用，如讀取硬件模塊數據，提供接口給硬件處理模塊來傳輸數據等。

4 診斷功能測試

當診斷功能完成以后，需要對整個系統進行測試，測試可分為黑盒測試和白盒測試。黑盒測試是功能性測試，僅限于測試項目的功能，對開發項目的邏輯和結構則不做過多的檢測；白盒測試則是針對代碼的邏輯和結構進行測試。本文只分析黑盒測試，即分析測試項目功能是否滿足要求。

當硬件連接完成后，打開上位機通信軟件，輸入指令，驗證根據指令返回信息的準確性。上位機通信軟件中也提供了一些快捷按鍵，可以通過快捷按鍵找到需要的參數。上位機軟件通過IIC 與開發板連接，通知按照特定的格式將指令傳輸至開發板，然后由開發板按照指定的格式通過IIC 傳輸回上位機界面。前面的字節含義是代表了后續需要發送的字節長度，后面是診斷的通信格式，如果是診斷會話控制功能，則使用服務ID 0x10。不同的服務所需要傳輸的字節數是不同的，具體內容需要在需求分析階段與客戶達成一致。上位機通信軟件界面如圖4所示。

針對診斷的不同服務項目進行測試，分別測試正反饋和負反饋，測試是否滿足制定的需求。在指令格式不正確或儀表狀況不好的情況下，上位機發送指令時，儀表將返回負反饋，使開發人員可以及時根據結果找到負反饋對應的原因，及時高效地解決問題；如果儀表返回正反饋，則代表了功能正常，下一步需要確認返回的數據是否正確。

當測試完畢后，如果功能滿足最初制定的需求，則診斷模塊功能完成，可以集成到系統中，再對系統進行全功能測試。

5 結語

診斷是汽車測試中必不可少的一部分，可以在汽車出現故障時，幫助開發人員及時找到問題產生的原因，并且定位到具體的ECU，再根據ECU 內部的診斷策略，找到出現問題的具體位置，快速高效地確定故障原因。本文基于IIC 的汽車多聯屏，提出了診斷技術的研究策略，可為后續汽車多聯屏的功能開發提供參考。