在汽車電子軟件開發(fā)中，統(tǒng)一診斷服務（UDS）是實現(xiàn)車輛診斷、刷寫和監(jiān)控的核心協(xié)議。Communication Control服務（服務標識符0x28）是UDS協(xié)議中一個關鍵的功能控制服務，它允許診斷儀動態(tài)地管理車載網(wǎng)絡中各ECU的通信行為。本文將結合AUTOSAR基礎軟件（BSW）的實踐，深入詳解0x28服務的功能、配置及與底層通信棧的集成。

1. Communication Control服務（0x28）概述

Communication Control服務的主要目的是控制ECU內(nèi)部非診斷通信的發(fā)送與接收。例如，在ECU刷寫（編程會話）期間，為了確保診斷通信的帶寬和穩(wěn)定性，通常需要暫時禁止應用報文（如CAN信號）的發(fā)送。該服務允許診斷儀在特定診斷會話（如擴展會話）下，對ECU的通信通道（如CAN、LIN、FlexRay等網(wǎng)絡）進行啟停控制。

2. 服務請求與響應格式

• 請求格式：28 + SubFunction + ControlType + [CommunicationType]
• SubFunction（子功能）：高字節(jié)位表示抑制肯定響應位（SuppressPosRspMsgIndicationBit），低7位定義控制模式（如0x00=使能Rx和Tx，0x01=使能Rx但禁用Tx，0x02=禁用Rx但使能Tx，0x03=禁用Rx和Tx）。

• ControlType（控制類型）：指定控制是應用于所有通信（0x00）還是特定網(wǎng)絡（如0x01=CAN, 0x02=CAN FD, 0x03=以太網(wǎng)等）。

• CommunicationType（通信類型，可選）：當ControlType指定特定網(wǎng)絡時，此參數(shù)進一步細化控制對象（如具體的通道ID或報文ID）。

• 肯定響應格式：68 + SubFunction（回顯請求中的子功能）
• 否定響應碼（NRC）：常見的有0x12（子功能不支持）、0x13（報文長度或格式錯誤）、0x22（條件不滿足，如不在擴展會話中）、0x31（請求超出范圍，如不支持的通道）。

3. AUTOSAR基礎軟件中的配置詳解

在AUTOSAR方法論中，0x28服務的實現(xiàn)和配置主要涉及診斷通信管理器（Dcm）、通信管理器（ComM）以及底層通信驅動（如CanIf、EthIf）。

3.1 Dcm模塊配置（Dcm模塊）

在Dcm配置中，需要為0x28服務定義服務表（DcmDspService）。關鍵配置項包括：

• 服務標識符：0x28。
• 會話與安全訪問控制：通常，Communication Control服務僅在非默認會話（如擴展會話或編程會話）下可用，并且可能需要特定的安全訪問等級。這需要在DcmDspSessionControl中關聯(lián)。
• 子功能支持：定義ECU支持的子功能列表（如0x00, 0x01, 0x02, 0x03）。
• 數(shù)據(jù)參數(shù)處理：配置對ControlType和可選CommunicationType參數(shù)的處理邏輯，包括數(shù)據(jù)長度和有效性檢查。

3.2 ComM模塊集成與配置

ComM是AUTOSAR中管理網(wǎng)絡通信模式的中心模塊。0x28服務的核心邏輯往往通過調(diào)用ComM的API來實現(xiàn)。

• 通信模式管理：當收到有效的0x28請求時，Dcm模塊應調(diào)用ComM<em>RequestComMode或ComM</em>InhibitCommunication等API，通知ComM改變指定通道的通信模式（FULLCOMMUNICATION, SILENTCOMMUNICATION, NO_COMMUNICATION）。
• 通道映射配置：在ComM配置中，需明確定義網(wǎng)絡通道標識符（如ComMChannelId）與物理通信通道（如Can控制器通道）的映射關系。這確保了0x28請求中的ControlType能正確映射到目標網(wǎng)絡。

3.3 通信接口層配置（CanIf, EthIf等）

ComM的模式控制最終會傳遞到通信接口層。

• 通信控制API：CanIf、EthIf等模塊提供了CanIf<em>Control、EthIf</em>Control等函數(shù)，用于執(zhí)行具體的通信啟停操作（如禁止報文發(fā)送/接收）。
• 配置關聯(lián)：需要確保ComM的通道配置與通信接口層的通道配置一致，使得控制指令能正確下達。

4. 實戰(zhàn)配置流程與示例

1. 定義需求：明確ECU需要支持哪些子功能（例如，刷寫時只需禁用Tx），以及控制哪些網(wǎng)絡通道（如CAN Channel 0）。
2. BSW模塊配置：

• 在Dcm配置中，啟用0x28服務，綁定到擴展會話，配置支持的子功能為0x01（禁用Tx）。

• 在ComM配置中，創(chuàng)建一個ComMChannel（例如ID=0），并將其與CanIf/Can的ControllerRef關聯(lián)。

• 配置Dcm與ComM的交互：在Dcm代碼中，實現(xiàn)0x28服務的回調(diào)函數(shù)，當收到子功能0x01請求時，調(diào)用ComM<em>InhibitCommunication(0, COMM</em>INHIBIT)。

1. 通信棧聯(lián)動：配置ComM，使其在進入SILENTCOMMUNICATION模式時，通過CanIf的CanIf</em>Control API，將對應CAN控制器的發(fā)送功能禁用。

5. 注意事項與最佳實踐

• 會話依賴：務必正確配置會話保護，避免在默認會話下誤操作影響車輛正常通信。
• 狀態(tài)恢復：當診斷會話退出（如退回默認會話）時，應確保通信狀態(tài)自動恢復。這通常通過ComM的自動狀態(tài)機管理或Dcm的會話層回調(diào)函數(shù)實現(xiàn)。
• 網(wǎng)絡管理協(xié)同：如果ECU支持AUTOSAR網(wǎng)絡管理（NM），需注意Communication Control服務與NM模式的協(xié)同，防止沖突。通常，ComM會協(xié)調(diào)NM和診斷的通信需求。
• 安全性考慮：在可能影響車輛安全功能的通道上執(zhí)行禁用操作時，應增加額外的安全訪問或預條件檢查。

###

Communication Control服務（0x28）是連接UDS診斷層與AUTOSAR通信棧的關鍵樞紐。通過精準的Dcm、ComM及通信接口層配置，可以實現(xiàn)對ECU通信行為的靈活、安全控制，為診斷、編程和測試等場景提供堅實基礎。理解各BSW模塊間的交互關系，是成功集成此服務的關鍵。