收到一條需求ECU 需要支持 0x28 服務(wù)CommunicationControl請?jiān)O(shè)計(jì)測試用例。這是診斷測試?yán)锓浅３Ｒ姷娜蝿?wù)但很多測試工程師的第一反應(yīng)是把 ISO 14229 里的請求、響應(yīng)表格抄一遍寫出一條“發(fā)送 02 28 03 01期望收到 02 68 03”的用例然后任務(wù)就算完成了。但這條用例真的能證明 0x28 服務(wù)實(shí)現(xiàn)正確嗎不能。它只能證明診斷儀和 ECU 之間完成了一次“報(bào)文格式正確”的交互證明不了 ECU 是否真的把應(yīng)用報(bào)文關(guān)掉了也證明不了通信行為能否在預(yù)期的時(shí)間點(diǎn)恢復(fù)更證明不了關(guān)閉通信后對(duì) DTC、網(wǎng)絡(luò)管理、其他診斷服務(wù)產(chǎn)生的連帶影響。0x28 服務(wù)測的不是“請求和響應(yīng)能對(duì)上”而是“通信行為真的被改變了嗎”。這篇文章我們從協(xié)議原理、需求拆解、正常/異常用例、組合場景、自動(dòng)化執(zhí)行和工程化沉淀幾個(gè)維度把 0x28 服務(wù)的用例設(shè)計(jì)完整走一遍。讀完以后你可以根據(jù)手頭的需求文檔直接產(chǎn)出一套可追溯、可回歸、可自動(dòng)化的 0x28 測試用例集。1. 0x28 服務(wù)的協(xié)議本質(zhì)與應(yīng)用場景先明確概念。0x28 服務(wù)全稱是 CommunicationControl中文叫“通信控制”是 UDSISO 14229-1協(xié)議族里用于控制 ECU 通信行為的服務(wù)。它解決的核心問題是在不改變線束、不重新上電、不刷寫軟件的前提下診斷儀或測試設(shè)備可以通過一條診斷請求讓 ECU 動(dòng)態(tài)打開或關(guān)閉某一類報(bào)文的接收和發(fā)送。這個(gè)能力看上去簡單實(shí)際應(yīng)用場景非常多產(chǎn)線下線檢測時(shí)需要讓 ECU 進(jìn)入靜默模式避免干擾產(chǎn)線上的其他測試。軟件刷寫前需要關(guān)閉應(yīng)用報(bào)文減少總線負(fù)載或避免 ECU 在刷寫過程中執(zhí)行非預(yù)期動(dòng)作。臺(tái)架調(diào)試時(shí)需要單獨(dú)關(guān)閉某一路 CAN 報(bào)文觀察其他節(jié)點(diǎn)行為。整車網(wǎng)絡(luò)問題排查時(shí)需要臨時(shí)隔離某一個(gè) ECU驗(yàn)證網(wǎng)絡(luò)拓?fù)渥兓?x28 的請求格式比較簡單SID 0x28 Sub-function 控制類型 CommunicationType 通信類型其中 Sub-function 是“控制動(dòng)作”CommunicationType 是“控制對(duì)象”。ISO 14229-1 中常見的子功能定義如下Sub-function含義0x00enableRxAndTx開啟接收和發(fā)送0x01enableRxAndDisableTx開啟接收關(guān)閉發(fā)送0x02disableRxAndEnableTx關(guān)閉接收開啟發(fā)送0x03disableRxAndTx關(guān)閉接收和發(fā)送0x04enableRxAndDisableTx with enhanced address info0x05disableRxAndEnableTx with enhanced address infoCommunicationType 是一個(gè)字節(jié)按位定義控制對(duì)象。常見定義如下Bit含義0 (0x01)Application應(yīng)用報(bào)文1 (0x02)Diagnostic診斷報(bào)文2 (0x04)Network Management網(wǎng)絡(luò)管理報(bào)文注意這些 bit 可以組合例如0x05表示同時(shí)控制“應(yīng)用報(bào)文 網(wǎng)絡(luò)管理報(bào)文”。另外不同主機(jī)廠的項(xiàng)目規(guī)范可能會(huì)裁剪這個(gè)字節(jié)的可用組合這也是后面用例設(shè)計(jì)時(shí)一定要查閱需求文檔的原因?？隙憫?yīng)的格式是SID 0x40 0x68 Sub-function例如請求28 03 01 響應(yīng)68 03如果請求無法執(zhí)行ECU 會(huì)返回否定響應(yīng)7F 28 NRC常見的 NRC 包括0x13、0x22、0x31、0x33、0x7E等后面會(huì)詳細(xì)展開。到這里我們對(duì) 0x28 的協(xié)議層已經(jīng)有了一個(gè)完整圖像。接下來要討論的問題是為什么很多用例設(shè)計(jì)會(huì)漏測漏在哪里。2. 0x28 服務(wù)用例設(shè)計(jì)的常見誤區(qū)我見過很多 0x28 相關(guān)測試用例問題非常集中。先總結(jié)成五個(gè)誤區(qū)你可以對(duì)號(hào)入座。2.1 誤區(qū)一格式通了就算測完典型的低質(zhì)量用例是這樣的步驟 1發(fā)送 28 03 01 預(yù)期收到 68 03這條用例只驗(yàn)證了請求和響應(yīng)格式。它沒有驗(yàn)證應(yīng)用報(bào)文到底停了沒有停的是發(fā)送還是接收停了之后怎么恢復(fù)恢復(fù)后應(yīng)用報(bào)文是否按原來的周期繼續(xù)發(fā)送真正的 0x28 測試預(yù)期結(jié)果一定要落到“總線上的實(shí)際報(bào)文行為”。比如預(yù)期ECU 發(fā)送 0x68 03 響應(yīng) 預(yù)期在收到響應(yīng)后的 100ms 內(nèi)總線上不再出現(xiàn) ECU 的應(yīng)用報(bào)文 ID 0x1A0 預(yù)期執(zhí)行恢復(fù)請求后應(yīng)用報(bào)文 ID 0x1A0 恢復(fù)發(fā)送周期為 20ms。只有這樣的用例才能證明 ECU 的行為符合需求。2.2 誤區(qū)二不區(qū)分物理尋址和功能尋址診斷請求可以走物理尋址也可以走功能尋址。0x28 服務(wù)在兩種尋址方式下ECU 的處理邏輯可能完全不同。例如某 ECU 在需求里明確規(guī)定“0x28 僅支持物理尋址功能尋址時(shí)返回否定響應(yīng)”那么測試用例必須有物理尋址請求期待正常響應(yīng)。功能尋址請求期待否定響應(yīng)并且要明確 NRC 值。如果只測物理尋址功能尋址這條邏輯就沒有覆蓋到。2.3 誤區(qū)三忽略 sub-function 和 communicationType 的合法組合前面提到Protocol 里定義了0x00~0x05的子功能0x01/0x02/0x04的 communicationType 可以組合。但 ECU 實(shí)現(xiàn)往往只支持需求文檔里列出的組合。舉個(gè)例子需求只支持0x03 控制應(yīng)用報(bào)文但測試用例卻把0x00~0x05全部列了一遍認(rèn)為所有組合都應(yīng)該返回肯定響應(yīng)。這就屬于不看需求只抄協(xié)議。反過來如果需求里明確支持0x00開啟收發(fā)和0x03關(guān)閉收發(fā)用例卻沒有覆蓋0x00恢復(fù)那同樣漏測。2.4 誤區(qū)四不驗(yàn)證恢復(fù)機(jī)制0x28 關(guān)閉通信之后必須有恢復(fù)手段。常見的恢復(fù)條件包括執(zhí)行0x28 0x00 0x01重新開啟應(yīng)用報(bào)文的收發(fā)。ECU 執(zhí)行0x11重啟。診斷會(huì)話切換。進(jìn)入特定狀態(tài)例如編程會(huì)話。很多用例只測“關(guān)閉”不測“恢復(fù)”結(jié)果在臺(tái)架或?qū)嵻嚿蠄?zhí)行完關(guān)閉操作后ECU 一直處于靜默狀態(tài)測試系統(tǒng)誤以為 ECU 故障。恢復(fù)用例比關(guān)閉用例更重要因?yàn)榛謴?fù)失敗意味著 ECU 直接“失聯(lián)”。2.5 誤區(qū)五不考慮對(duì) DTC 和網(wǎng)絡(luò)管理的影響關(guān)閉應(yīng)用報(bào)文后ECU 可能因?yàn)槿鄙僬Ｍㄐ哦鴪?bào) DTC或者網(wǎng)絡(luò)管理報(bào)文停止導(dǎo)致其他節(jié)點(diǎn)認(rèn)為該節(jié)點(diǎn)“缺席”。這些結(jié)果并不一定是缺陷如果需求文檔里明確寫了“關(guān)閉通信期間需要禁止 DTC 置位”但 ECU 實(shí)際置位了那你設(shè)計(jì)用例時(shí)如果沒有 DTC 維度就發(fā)現(xiàn)不了這個(gè)問題。這一節(jié)的結(jié)論很明確0x28 用例設(shè)計(jì)的核心維度是“行為、交互、恢復(fù)”。接下來我們看怎么從需求文檔里把這三個(gè)維度的測試點(diǎn)拆出來。3. 從需求文檔中拆解 0x28 測試點(diǎn)的方法拿到需求文檔之后不要急著寫用例。先按照下面五個(gè)問題去拆解拆完以后測試點(diǎn)就自然出來了。3.1 問題一支持范圍是什么先確認(rèn)需求里寫了什么支持的服務(wù)子功能有哪些支持的 communicationType 有哪些支持物理尋址還是功能尋址在哪個(gè)診斷會(huì)話下支持這些信息可以從“診斷需求表”或“診斷規(guī)范”里找到。如果需求文檔沒寫就需要找診斷負(fù)責(zé)人確認(rèn)而不是自己猜。3.2 問題二控制對(duì)象是什么明確 0x28 控制的是應(yīng)用報(bào)文、診斷報(bào)文還是網(wǎng)絡(luò)管理報(bào)文。這個(gè)字段會(huì)直接影響測試時(shí)觀察哪一類報(bào)文。3.3 問題三前置條件是什么執(zhí)行 0x28 之前ECU 需要處于什么狀態(tài)是否需要在擴(kuò)展會(huì)話是否需要安全解鎖是否需要車輛處于某種工況這些前置條件必須寫進(jìn)用例里否則用例不可復(fù)現(xiàn)。3.4 問題四恢復(fù)條件是什么需求文檔里必須寫清楚恢復(fù)機(jī)制通過 0x28 0x00 恢復(fù)通過 ECU 重啟恢復(fù)通過會(huì)話切換恢復(fù)恢復(fù)時(shí)間有沒有要求3.5 問題五DTC 和事件行為是什么關(guān)閉通信后ECU 是否應(yīng)該禁止 DTC 置位是否應(yīng)該記錄診斷事件這些也要拆出來。下面用一個(gè)假設(shè)的需求條目來做一次完整拆解。注意這是一個(gè)示例實(shí)際項(xiàng)目以你的需求文檔為準(zhǔn)。假設(shè)需求條目如下ECU 在擴(kuò)展會(huì)話且安全解鎖狀態(tài)下接收到物理尋址的 0x28 服務(wù) sub-function 0x03communicationType 0x01 時(shí) 應(yīng)停止發(fā)送應(yīng)用報(bào)文并返回肯定響應(yīng)。 ECU 通過 0x11 重啟后應(yīng)恢復(fù)應(yīng)用報(bào)文發(fā)送。 在默認(rèn)會(huì)話下收到該請求應(yīng)返回 NRC 0x22。 該服務(wù)不支持功能尋址。拆解成測試點(diǎn)的結(jié)果如下需求屬性需求內(nèi)容對(duì)應(yīng)測試點(diǎn)前置會(huì)話擴(kuò)展會(huì)話默認(rèn)會(huì)話下測試 0x28預(yù)期 0x22安全等級(jí)需要安全解鎖未解鎖狀態(tài)下發(fā)送預(yù)期 0x33尋址方式僅物理尋址功能尋址發(fā)送預(yù)期否定響應(yīng)控制動(dòng)作0x03 disableRxAndTx驗(yàn)證應(yīng)用報(bào)文停止發(fā)送和接收控制對(duì)象0x01 Application關(guān)閉后應(yīng)用報(bào)文不再出現(xiàn)肯定響應(yīng)返回 0x68 0x03驗(yàn)證 SID 和 sub-function恢復(fù)機(jī)制ECU 重啟后恢復(fù)執(zhí)行 0x11驗(yàn)證應(yīng)用報(bào)文恢復(fù)發(fā)送這樣拆完以后一條需求可以映射出至少十幾條測試用例。接下來的兩個(gè)章節(jié)就是把這些測試點(diǎn)組織成正常場景用例和異常場景用例。4. 0x28 服務(wù)正常場景用例設(shè)計(jì)正常場景用例的定位是建立“請求-行為-恢復(fù)”的基線。也就是說在合法前提條件下ECU 應(yīng)該正確完成通信控制。先給一套推薦用例編號(hào)規(guī)范TC_028_N_xxxNormal正常場景。TC_028_I_xxxInvalid非法參數(shù)預(yù)期否定響應(yīng)。TC_028_B_xxxBoundary邊界值。TC_028_C_xxxCombination組合場景。下面是一組核心正常場景用例覆蓋了最常見的 sub-function 和 communicationType 組合。用例編號(hào)前置條件測試步驟預(yù)期結(jié)果TC_028_N_001擴(kuò)展會(huì)話安全解鎖發(fā)送 28 00 01收到 68 00應(yīng)用報(bào)文正常收發(fā)TC_028_N_002擴(kuò)展會(huì)話安全解鎖發(fā)送 28 01 01收到 68 01應(yīng)用報(bào)文接收正常、發(fā)送停止TC_028_N_003擴(kuò)展會(huì)話安全解鎖發(fā)送 28 02 01收到 68 02應(yīng)用報(bào)文發(fā)送正常、接收停止TC_028_N_004擴(kuò)展會(huì)話安全解鎖發(fā)送 28 03 01收到 68 03應(yīng)用報(bào)文收發(fā)停止TC_028_N_005擴(kuò)展會(huì)話安全解鎖先發(fā)送 28 03 01再發(fā)送 28 00 01恢復(fù)后應(yīng)用報(bào)文恢復(fù)收發(fā)TC_028_N_006默認(rèn)會(huì)話發(fā)送 28 00 02按需求返回肯定響應(yīng)或 NRC 0x22以項(xiàng)目規(guī)范為準(zhǔn)TC_028_N_007擴(kuò)展會(huì)話安全解鎖發(fā)送 28 03 05控制對(duì)象為應(yīng)用報(bào)文 網(wǎng)絡(luò)管理報(bào)文時(shí)兩類報(bào)文均停止TC_028_N_008擴(kuò)展會(huì)話安全解鎖連續(xù)發(fā)送 28 03 01 兩次第二次請求同樣返回肯定響應(yīng)行為保持停止?fàn)顟B(tài)注意幾點(diǎn)第一每條用例的“預(yù)期結(jié)果”不能只寫響應(yīng)幀。表里的 “應(yīng)用報(bào)文恢復(fù)收發(fā)” 這類描述執(zhí)行時(shí)需要通過總線工具觀察實(shí)際報(bào)文比如過濾0x1A0這個(gè) ID 的周期報(bào)文。第二TC_028_N_006這類用例如果需求文檔里沒有明確默認(rèn)會(huì)話的行為就不要拍腦袋寫預(yù)期。正確做法是在用例里標(biāo)注“待需求確認(rèn)”。第三如果 0x28 支持多個(gè) communicationType 組合那么正常用例還要覆蓋組合值。例如0x01 | 0x02 0x03表示同時(shí)控制應(yīng)用報(bào)文和診斷報(bào)文這時(shí)候預(yù)期結(jié)果要分別驗(yàn)證兩類報(bào)文的狀態(tài)。下面把TC_028_N_004和TC_028_N_005展開成詳細(xì)步驟因?yàn)檫@兩條用例最能體現(xiàn)“行為驗(yàn)證”的思路。TC_028_N_004詳細(xì)步驟確認(rèn) ECU 處于擴(kuò)展會(huì)話并已完成安全解鎖。在總線上確認(rèn)能夠收到 ECU 周期性發(fā)送的應(yīng)用報(bào)文 ID0x1A0。發(fā)送診斷請求28 03 01。等待并接收 ECU 的診斷響應(yīng)。記錄響應(yīng)幀斷言 SID 為0x68sub-function 為0x03。在響應(yīng)后的 500ms 內(nèi)持續(xù)監(jiān)聽總線上0x1A0報(bào)文斷言不再收到該報(bào)文。TC_028_N_005詳細(xì)步驟先執(zhí)行TC_028_N_004確認(rèn)應(yīng)用報(bào)文已停止。發(fā)送診斷請求28 00 01。等待并接收 ECU 的診斷響應(yīng)。記錄響應(yīng)幀斷言 SID 為0x68sub-function 為0x00。在響應(yīng)后的 500ms 內(nèi)持續(xù)監(jiān)聽總線上0x1A0報(bào)文斷言該報(bào)文恢復(fù)發(fā)送且發(fā)送周期符合需求定義。正常場景用例的重點(diǎn)是“可觀察”。如果你寫的預(yù)期結(jié)果里沒有總線報(bào)文行為那這條用例的測試強(qiáng)度就還差一層。5. 0x28 服務(wù)異常與邊界用例設(shè)計(jì)異常用例的目標(biāo)是驗(yàn)證 ECU 的防御能力請求不合法時(shí)ECU 能不能正確拒絕返回的 NRC 是否符合協(xié)議和項(xiàng)目規(guī)范。0x28 服務(wù)最常見的異常場景集中在以下五個(gè)維度。5.1 無效 sub-function如果把0x06、0xFF這類協(xié)議保留值或未支持值作為 sub-function 發(fā)送ECU 應(yīng)該返回否定響應(yīng)。常見的期望 NRC 是0x7ESubFunctionNotSupported或0x31RequestOutOfRange具體以項(xiàng)目規(guī)范為準(zhǔn)。5.2 無效 communicationTypecommunicationType 的保留 bit 被置為 1例如發(fā)送28 03 80ECU 需要判斷該值無效返回否定響應(yīng)。這里要特別關(guān)注有些 ECU 只校驗(yàn)0x01/0x02/0x04這幾個(gè) bit其他 bit 忽略有些 ECU 則嚴(yán)格校驗(yàn)全字節(jié)。設(shè)計(jì)用例前必須查看需求文檔對(duì) communicationType 校驗(yàn)范圍的定義。5.3 前置條件不滿足這是異常用例里最容易被忽略的一類。默認(rèn)會(huì)話下發(fā)送 0x28如果需求要求擴(kuò)展會(huì)話才能執(zhí)行則預(yù)期 NRC0x22。未解鎖狀態(tài)下發(fā)送需要安全等級(jí)的 0x28預(yù)期 NRC0x33。如果需求對(duì)尋址方式有限制功能尋址發(fā)送時(shí)也要有明確的否定響應(yīng)預(yù)期。5.4 報(bào)文長度錯(cuò)誤0x28 請求的長度是 3 個(gè)字節(jié)SID sub-function communicationType。如果發(fā)送28 03 // 缺少 communicationType 28 03 01 FF // 多出一個(gè)字節(jié)ECU 應(yīng)該返回0x13IncorrectMessageLengthOrInvalidFormat。注意某些 ECU 在收到“SID 正確但長度錯(cuò)誤”的請求時(shí)會(huì)執(zhí)行長度校驗(yàn)并返回0x13也有 ECU 先判斷 sub-function再判斷長度返回的 NRC 可能不同。所以長度錯(cuò)誤用例的預(yù)期 NRC 需要結(jié)合實(shí)際實(shí)現(xiàn)確認(rèn)。5.5 重復(fù)請求與順序異常重復(fù)請求不一定都是正常場景。比如ECU 當(dāng)前已經(jīng)處于“應(yīng)用報(bào)文關(guān)閉”狀態(tài)再次發(fā)送28 03 01有些 ECU 會(huì)冪等地返回肯定響應(yīng)有些則會(huì)返回0x22。這就是一個(gè)典型的需求不明確點(diǎn)應(yīng)該列為待確認(rèn)用例。再比如先發(fā)送28 01 01禁止發(fā)送不發(fā)送任何恢復(fù)請求直接切換會(huì)話。切換后 ECU 是保持原狀態(tài)還是恢復(fù)默認(rèn)通信狀態(tài)這類用例必須在整車或臺(tái)架上實(shí)際驗(yàn)證不能靠猜。下面是一組常用的異常用例表用例編號(hào)前置條件測試步驟預(yù)期 NRCTC_028_I_001擴(kuò)展會(huì)話安全解鎖發(fā)送 28 06 010x7E 或 0x31TC_028_I_002擴(kuò)展會(huì)話安全解鎖發(fā)送 28 FF 010x7E 或 0x31TC_028_I_003擴(kuò)展會(huì)話安全解鎖發(fā)送 28 03 800x31TC_028_I_004默認(rèn)會(huì)話發(fā)送 28 03 01若需求要求擴(kuò)展會(huì)話0x22TC_028_I_005擴(kuò)展會(huì)話未解鎖發(fā)送 28 03 01若需求要求安全等級(jí)0x33TC_028_I_006擴(kuò)展會(huì)話安全解鎖發(fā)送 28 030x13TC_028_I_007擴(kuò)展會(huì)話安全解鎖發(fā)送 28 03 01 FF0x13TC_028_B_001擴(kuò)展會(huì)話安全解鎖發(fā)送 28 03 00communicationType 無效值0x31有一類邊界用例特別值得寫communicationType 0x00。ISO 14229 里0x00一般不是合法控制對(duì)象但不同 OEM 的裁剪可能不同。這種“協(xié)議沒明確、規(guī)范可能變”的邊界值用例里一定要保留并在評(píng)審時(shí)和診斷工程師確認(rèn)最終預(yù)期。6. 0x28 服務(wù)與其他診斷服務(wù)的組合場景用例0x28 在真實(shí)項(xiàng)目里不會(huì)孤立運(yùn)行它總是和會(huì)話控制、安全訪問、ECU 重啟、DTC 設(shè)置等服務(wù)組合出現(xiàn)。組合場景用例是故障排查價(jià)值最高的用例也是最能體現(xiàn)測試深度的部分。6.1 0x28 與 0x10 會(huì)話控制組合典型場景ECU 在擴(kuò)展會(huì)話下執(zhí)行28 03 01應(yīng)用報(bào)文停發(fā)。測試直接切換到編程會(huì)話檢查應(yīng)用報(bào)文是否仍然停發(fā)。再從編程會(huì)話切回?cái)U(kuò)展會(huì)話檢查 0x28 的通信控制狀態(tài)是否保持。這類用例驗(yàn)證的是會(huì)話切換對(duì) 0x28 狀態(tài)的影響。不同 ECU 的處理策略不同有的切換會(huì)話會(huì)清除通信控制狀態(tài)有的則保持原狀態(tài)。6.2 0x28 與 0x27 安全訪問組合如果 0x28 需要安全等級(jí)未解鎖時(shí)發(fā)送28 03 01預(yù)期0x33。執(zhí)行 0x27 解鎖后發(fā)送28 03 01預(yù)期成功。解鎖后等待 SecurityAccess 超時(shí)鎖定再發(fā)送28 03 01預(yù)期返回0x33。6.3 0x28 與 0x11 ECU 重啟組合這是最常用的恢復(fù)手段必須覆蓋執(zhí)行28 03 01應(yīng)用報(bào)文停發(fā)。執(zhí)行11 01ECU 重啟。重啟后檢查應(yīng)用報(bào)文是否恢復(fù)發(fā)送。這里有一個(gè)容易被忽略的細(xì)節(jié)重啟后0x28 的“關(guān)閉狀態(tài)”是否被清除如果 ECU 重啟后依然保持關(guān)閉狀態(tài)那說明 ECU 把通信控制狀態(tài)保存到了非易失存儲(chǔ)行為是否符合需求需要和開發(fā)確認(rèn)。6.4 0x28 與 0x85 DTC 設(shè)置組合關(guān)閉應(yīng)用報(bào)文后ECU 可能因?yàn)槿鄙賰?nèi)部通信或外部報(bào)文而置位 DTC。組合用例應(yīng)驗(yàn)證需求允許置 DTC則確認(rèn) DTC 狀態(tài)置位。需求禁止置 DTC則確認(rèn) DTC 狀態(tài)未改變。這類用例在實(shí)車測試中尤其重要因?yàn)?DTC 誤置位會(huì)直接影響售后診斷。6.5 0x28 與 0x22 數(shù)據(jù)讀取組合如果 communicationType 只關(guān)閉了應(yīng)用報(bào)文診斷報(bào)文應(yīng)該仍然可用。組合用例可以驗(yàn)證執(zhí)行28 03 01后發(fā)送22 F1 90讀取數(shù)據(jù)確認(rèn) ECU 仍然響應(yīng)。如果 communicationType 同時(shí)包含了0x02則執(zhí)行22 F1 90時(shí)預(yù)期無響應(yīng)或行為變化。6.6 0x28 與網(wǎng)絡(luò)管理組合當(dāng) communicationType 包含0x04網(wǎng)絡(luò)管理時(shí)0x28 會(huì)關(guān)閉網(wǎng)絡(luò)管理報(bào)文。這時(shí)候整車網(wǎng)絡(luò)里的其他節(jié)點(diǎn)會(huì)認(rèn)為該 ECU 掉線可能觸發(fā)網(wǎng)絡(luò)管理相關(guān)的 DTC。組合用例應(yīng)驗(yàn)證關(guān)閉網(wǎng)絡(luò)管理報(bào)文后其他節(jié)點(diǎn)是否在預(yù)期時(shí)間內(nèi)檢測到該節(jié)點(diǎn)缺席?；謴?fù)網(wǎng)絡(luò)管理報(bào)文后網(wǎng)絡(luò)是否恢復(fù)正常狀態(tài)。這一組組合場景核心要點(diǎn)是“時(shí)序”。每條用例都要清楚寫出先執(zhí)行什么、等待多久、再執(zhí)行什么。7. 0x28 服務(wù)測試環(huán)境搭建與自動(dòng)化示例設(shè)計(jì)完用例之后就要考慮執(zhí)行。0x28 服務(wù)測試離不開總線工具。這里以 CANoe / CAPL 和 python-can 為例給出可落地的自動(dòng)化示例。7.1 環(huán)境準(zhǔn)備硬件支持 CAN 的接口卡例如 Vector、PCAN、ValueCAN 等。軟件CANoe / CANalyzer或 Python 3 python-can?？偩€數(shù)據(jù)庫需要包含測試對(duì)象的報(bào)文 ID、周期、信號(hào)定義。診斷數(shù)據(jù)庫如果使用診斷功能建議提前導(dǎo)入 CDD/ODX。測試對(duì)象ECU 或臺(tái)架確保 CAN 通道、終端電阻、波特率正確。這里給出一個(gè)約定測試 ECU 的診斷請求 ID 為0x7E0響應(yīng) ID 為0x7E8應(yīng)用報(bào)文 ID 為0x1A0波特率 500kbps。實(shí)際項(xiàng)目請按真實(shí) DBC 和診斷數(shù)據(jù)庫修改。7.2 CAPL 示例發(fā)送 0x28 請求并驗(yàn)證響應(yīng)下面是一個(gè)簡化版 CAPL 測試用例。它的邏輯是發(fā)送28 03 01等待響應(yīng)判斷 SID 和 sub-function并檢查應(yīng)用報(bào)文是否停止。// CAPL 示例0x28 服務(wù)發(fā)送與響應(yīng)驗(yàn)證 variables { const int DIAG_REQ_ID 0x7E0; const int DIAG_RES_ID 0x7E8; const int APP_MSG_ID 0x1A0; message DIAG_REQ_ID reqMsg; message DIAG_RES_ID resMsg; int appMsgReceived 0; } // 發(fā)送 0x28 請求sub-function0x03, communicationType0x01 void SendCommunicationControlRequest() { reqMsg.byte(0) 0x03; // PCI單幀數(shù)據(jù)長度 3 reqMsg.byte(1) 0x28; // SIDCommunicationControl reqMsg.byte(2) 0x03; // sub-functiondisableRxAndTx reqMsg.byte(3) 0x01; // communicationTypeApplication output(reqMsg); } // 統(tǒng)計(jì)應(yīng)用報(bào)文是否出現(xiàn) on message APP_MSG_ID { appMsgReceived 1; } testcase TC_028_N_004_CAPL() { appMsgReceived 0; SendCommunicationControlRequest(); // 等待診斷響應(yīng) if (testWaitForMessage(DIAG_RES_ID, 1000)) { if (resMsg.byte(1)