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

1. Communication Control服務(wù)（0x28）概述

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

2. 服務(wù)請(qǐng)求與響應(yīng)格式

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

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

• CommunicationType（通信類型，可選）：當(dāng)ControlType指定特定網(wǎng)絡(luò)時(shí)，此參數(shù)進(jìn)一步細(xì)化控制對(duì)象（如具體的通道ID或報(bào)文ID）。

• 肯定響應(yīng)格式：68 + SubFunction（回顯請(qǐng)求中的子功能）
• 否定響應(yīng)碼（NRC）：常見(jiàn)的有0x12（子功能不支持）、0x13（報(bào)文長(zhǎng)度或格式錯(cuò)誤）、0x22（條件不滿足，如不在擴(kuò)展會(huì)話中）、0x31（請(qǐng)求超出范圍，如不支持的通道）。

3. AUTOSAR基礎(chǔ)軟件中的配置詳解

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

3.1 Dcm模塊配置（Dcm模塊）

在Dcm配置中，需要為0x28服務(wù)定義服務(wù)表（DcmDspService）。關(guān)鍵配置項(xiàng)包括：

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

3.2 ComM模塊集成與配置

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

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

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

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

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

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

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

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

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

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

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

5. 注意事項(xiàng)與最佳實(shí)踐

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

###

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