整個診斷汽車管理包括診斷通信管理(Diagnostic Communication Manager, DCM)、診斷事件管理DEM（Diagnostic Event Manager）、功能抑制管理FIM（Function Inhibition Manager）幾大模塊。

診斷功能貫穿汽車的開發生產及售后等過程，如開發過程中EMC、ESD等實驗均可使用診斷服務實現，生產過程中的軟件下載更新、ECU產線EOL、汽車產線EOL等、售后過程中讀取DTC、控制輸出調試功能等。

尤其是在智能汽車上，診斷功能顯得尤為重要，因為智能汽車的很多功能模塊需要承載更多的Sensor和Controller，且其功能都是自適應觸發。因此，對于其自身系統及其關聯系統的診斷要求比傳統汽車要高很多。

如下圖，表示了AUTOSAR架構中的所有診斷通信模塊之的關聯關系。在底層軟件中，包括模式管理Mode Manager、診斷Diagnosis、存儲Memory、通信Communication幾個模塊。

在AUTOSAR中，DCM和DEM是兩個關鍵的診斷模塊，它們之間通過一些通信鏈路相互作用。DCM主要負責與外部診斷工具（例如診斷掃描儀）進行通信，以便讀取和清除故障碼，并執行一些診斷任務。DEM則負責管理和記錄車輛的診斷事件，例如故障碼、診斷狀態和診斷數據等。

診斷通信管理模塊DCM

作為AutoSar診斷模塊的重要組成部分，DCM主要負責診斷數據流和管理診斷狀態（即能檢查診斷服務的請求是否滿足條件），包括診斷會話、安全狀態及診斷服務分配等。DCM模塊主要實現UDS和OBD診斷服務的實現，但是DCM跟其他模塊的交互比較頻繁，需要了解診斷服務的機制需要其他模塊配置，比如BswM、DEM、EcuM以及SWC等。

DCM模塊可以分為四個子層，分別是DSD（Diagnostic Session Dispatcher）、DSL（Diagnostic Service Layer）、DSP（Diagnostic Service Processor）和DCL（Diagnostic Communication Layer）。在這個上下文中，DCM、DSD、DSL和DSP之間的關系可以描述如下：

1、DSL ：診斷服務層。

該層處于DCM模塊的最底層，用于處理診斷數據請求和響應的數據流；監控和確保診斷請求和響應的時序。它接收來自DSD層的診斷請求，并根據請求類型將其路由到相應的DSP子層服務。同時，DSL也負責將來自DSP子層的診斷響應傳輸回DSD層。

整個處理診斷請求及響應的過程如下：

DSL負責接收PduR模塊上傳的診斷請求及調用PduR模塊發送診斷響應數據，管理并確保診斷協議時序和診斷狀態（如當前安全級別保存和復位，當前會話狀態，默認會話與非默認會話之間的轉換，對不同診斷協議優先級定義和搶占處理）。

2、DSD：診斷會話調度器。

處于中間層，這個子層主要負責管理診斷會話，如處理診斷會話切換、請求取消、會話超時等功能。此外，它還負責將來自DCL層的診斷請求轉發到相應的DSL層服務。

當接收到新的診斷請求后轉發到診斷服務器，完成診斷請求處理后轉發診斷響應。

3、DSP：診斷服務處理器。

處于最上層，具體實施診斷服務處理，當接受到DSD請求處理診斷服務并轉發診斷請求后，將完成實際的診斷服務功能響應及處理。它包含了處理不同診斷服務（如讀取故障碼、控制執行、數據參數ID請求等）所需的功能。每個具體的診斷服務都可以看作是一個獨立的DSP子層。

DCM作為診斷通信管理器，通過DSD負責診斷會話管理，DSL處理診斷服務請求和響應，而DSP負責實施具體的診斷服務，以上各子層的協同作用可以有效的實現各種診斷服務的處理和響應。

診斷事件管理（DEM）

DEM負責處理車輛的故障診斷信息。DEM模塊可以接收來自各種傳感器和控制器的診斷信息，然后根據故障嚴重程度進行分類和記錄，并提供診斷狀態和故障碼等信息。

此外，DEM還提供了一些API（應用程序接口），用于訪問和修改診斷數據。例如，可以使用API來清除已診斷的故障碼或設置故障碼的優先級。DEM還提供了診斷通信協議和診斷存儲庫，以便與其他系統進行通信和記錄診斷數據。

DCM和DEM之間的通信鏈路主要包括以下組件：

1）DCM提供的API： DCM提供了一些API，用于從DEM中讀取和更新診斷數據，例如讀取故障碼和清除故障碼等。

2）DEM提供的API： DEM也提供了一些API，用于向DCM提供診斷信息，例如故障碼、診斷狀態和診斷數據等。

3）DCM-DEM通信協議： DCM和DEM之間的通信需要使用一些標準化的通信協議，例如UDS（Unified Diagnostic Services）協議和ISO 14229標準。

4）診斷存儲庫： DCM和DEM需要共享一些診斷數據，例如故障碼和診斷狀態等，這些數據通常存儲在診斷存儲庫中，DCM和DEM可以通過這個存儲庫來交換數據。

舉個例子，我們在對智能汽車生產線過電檢時，通常需要關閉智能駕駛的環境目標檢測及后臺自啟動功能（如AEB、MEB這類后臺自動運行的功能），因為這些功能在產線上自動運行往往會導致誤觸發，誤報警等。

那么如何通過診斷管理鏈路關閉這類功能呢？

這就需要用到AutoSar中非常重要的兩個軟件組件模塊診斷事件管理DEM和實時調度系統RTE。他們之間的通信鏈路可以通過AUTOSAR的標準化軟件接口RTE APIs來實現。首先，DEM模塊可以向RTE模塊發送事件（例如功能抑制信息或故障碼、診斷狀態信息）。RTE模塊接收到這些事件后，通過其自身提供的一些API，RTE事件總線通過管理和分發來自DEM和其他模塊的事件，并將它們路由到相應的處理程序中。此外，RTE操作系統作為一種特殊的軟件層，它負責管理和控制運行時環境，并提供一些基礎設施服務，例如任務調度、內存管理和錯誤處理等。從而有效的訪問汽車電子系統的各種資源，例如讀取傳感器數據、控制執行器等。也可以觸發相應的操作，例如關閉AEB或MEB功能，亦或者打開某個告警燈等。

為了更加詳細的說明整個DEM的診斷鏈路，我們將以實際的DEM相關函數調用為例進行有效的說明。

首先，DEM的API主要包括DEM監視器DemComponent（又名MonitorComponent），主要用于有關聯到的故障事件，比如傳感器本身發生的故障，這時控制器讀取的數據應該被視為無效。一個DemComponent是若干個事件的集合，在DemComponent內部，故障事件有優先級，當最高優先級的故障事件狀態為Failed從而導致其他故障事件也為Failed時，亦或者父節點DemComponent的狀態為Failed從而導致子節點DemComponent內的故障事件狀態變為Failed，這種叫連續錯誤的故障。其他則被認為是偶發錯誤故障。另外，如果DemComponent內部故障事件優先級被忽略，那么僅有當父節點DemComponent狀態為Failed導致子節點DemComponent的故障事件狀態變成Failed時，也可被當做連續錯誤。

其次，DemDTCAttributes可以用于配置DTC的屬性，包括老化周期、故障優先級、存儲方式（立即存儲還是下電存儲）、快照數據需記錄的最大組數以及參考的凍結幀快照數據、故障數據存儲的Memory等，其中快照數據、擴展數據等需要在DemGneral中進行配置。

DemDTC用于配置故障得DTC值（即診斷故障碼）、DTC的嚴重弄程度以及參考的DTC屬性、Obd屬性等。

DemDebunceCounterBaseClass、DemDebounceTimeBaseClass兩項主要用于為不同的故障事件配置不同的Debounce策略，可以是基于計數器的Debounce策略，也可以是基于事件的Debounce策略，或者由SWC自定義。

DemOBDDTC用于配置OBD類故障事件是否支持PTO以及故障事件的DTC值等。

DemPidClass用于配置PID以及相關的應用層信號。

DemEventParameter用于配置故障的類型（BSW或SWC）、故障需要多少個運行循環才能確認、是否支持預存儲功能、故障事件的Debounce策略以及參考的DTC屬性、DemComponent、使能條件、運行循環等。

功能抑制管理FIM

FIM實際是一種軟件組件，用于實現對應功能的抑制管理。功能抑制是指在車輛故障或安全問題出現時，對某些汽車功能進行限制或禁用的操作，以保證車輛和乘客的安全。FIM組件通過AUTOSAR的標準化軟件接口（FIM API）與其他軟件組件（例如ECU、Sensor和Actuator）進行通信，以檢測和響應車輛故障或安全問題，并執行相應的功能抑制措施。

FIM的主要功能邏輯就是基于DEM模塊上報Event狀態，來觸發相應的FID，然后BSW層或者SWC層相關的子模塊根據這些FIM功能抑制場景（也就是功能降級）。

這里舉個自動窗戶升降與防夾功能的例子來說明如何通過FIM相關的函數模塊來調用Sensor SWC層中的Event anti_Pinch，并通過下面幾個階段來完成系統降級過程。

S1：Front-left Window-lifter SWC上報故障給到Error Management模塊；

S2：Error Management模塊會識別出為Event anti_Pinch故障，并調用Dem模塊接口通知該Event Status發生變化；

S3：Dem模塊會調用FIM模塊相應的函數接口來通知FIM該Event Status對相應FID的影響；

S4：SWC模塊接收到輪詢的FID，然后完成相應的系統降級響應；

FIM模塊提供了一些API（應用程序接口），用于訪問和修改功能抑制狀態、讀取和更新診斷數據等。這些API通常是標準化的，符合AUTOSAR軟件架構的規范。

FIM模塊主要調用的API接口包括如下：

FIM_Init()：此API用于初始化FIM模塊，包括初始化內部數據結構、變量和狀態等。

該函數是用于完成FIM相關結構體的初始化工作。如果DET模塊使能，可以判斷FIM是否初始化成功，或者可以通過一個靜態變量判斷是否發生變化來判斷初始化是否完成。因為如果FIM模塊沒有完成初始化，則會被其他模塊調用其內部的函數，且會返回E_NOT_OK，所以調用FIM其他函數接口之前必須完成FIM模塊的初始化。

FIM_InhibitFunction()：此API用于抑制特定的汽車功能。它需要輸入功能ID和抑制級別等參數，并返回抑制狀態和抑制結果等信息。

FIM_ReleaseFunction()：此API用于釋放被抑制的汽車功能。它需要輸入功能ID等參數，并返回釋放狀態和釋放結果等信息。

FIM_GetStatus()：此API用于獲取FIM模塊的當前狀態，例如抑制狀態、抑制等級和抑制時間等。

FIM_GetDiagnosticData()：此API用于讀取和更新FIM模塊的診斷數據，例如故障碼和診斷狀態等。

如下將以具體的實例參數調用來說明如何進行功能抑制。

FIM_DemTriggerOnMonitorStatus：

該函數是為了提供給Dem模塊Event Status發生變化時通知到FIM模塊接口。一旦Event Status發生變化，Dem就會主動調用該函數，通知FIM，其本質上就是一種Trigger Action行為。其實FIM獲取Event Status狀態變化，還有一種Polling的方式，但是當Event數目比較大時，有時候就無法察覺到某些Event Status的快速變化，因此一般而言，都優先選擇Trigger方式來完成對FIM模塊的Event Status的通知。

FIM_GetFunctionPermission：

該函數提供給SWC或BSW模塊來獲取FID狀態。如果請求FID超出范圍或FIM模塊還沒有初始化完成，則FID就會直接退回FALSE。

FIM_GetFunctionAvailable：

該函數用來給BSW或SWC層設置某功能是否可用，如果輸入參數為True，則該功能可以正常使用

FIM_SetFunctionAvailable：

該函數用來給BSW或SWC層來設置某功能是否可用，如果輸入參數為TRUE，那么該功能可以正常使用。若輸入參數為FALSE，則該功能就會被Disable。

FIM_MainFunction：

該函數是為了實現對Event Status與Inhibition Mask的計算，此處有兩種方式，一種是Polling方式，另一種是Event Trigger方式，這兩種方式的使能通過工具選項FIMEventUpdate TriggeredByDem是否為True決定。