前言

1. 个人学习使用，请勿转载；
2. 后续会更新CAN DiVa其他章节的测试用例分析；
3. 难以避免地，部分Test Case测试结果为Fail，请注意识别。

Transport Layer

CAN总线Transport Layer依据ISO 15765-2协议实现，基础知识请参考此篇笔记：UDS ON CAN 时间参数

Test CaseID-TP1: TP1_AbortTransmission

• 标题: TP1_AbortTransmission
• 标准依据: ISO 15765-2第6章（多帧通信协议）
• 测试方法: 在传输多帧请求时，在发送了 17 个字节后中止传输。不期望收到响应。

Test CaseID-TP2: TP2_No_CF

• 标题: TP2_No_CF
• 标准依据: ISO 15765-2第6章（多帧通信协议）
• 测试方法: Tester先发送诊断请求，期待收到DUT诊断响应。Tester发送一个多帧请求，不要发送任何连续帧（CF），期待DUT不进行回复。

Test CaseID-TP3: TP3_Drop_CF

• 标题: TP3_Drop_CF
• 标准依据: ISO 15765-2第6章（多帧通信协议）
• 测试方法: 发送一个需要超过4帧的请求。丢弃第三个连续帧（CF）。ECU不应响应。
• 说明：仿真连续帧丢失的场景，请注意：实际测试中Tester是丢弃的第一个连续帧。

Test CaseID-TP4: TP4_Double_Frame

• 标题: TP4_Double_Frame
• 标准依据: /
• 测试方法: 向ECU发送一个多帧消息。将第一个连续帧（CF）发送两次。不期望任何响应，当接收到无效的序列号时，ECU会终止接收。
• 特点：重复流控帧，且ECU应终止接收不响应。

Test CaseID-TP5: TP5_Delay_CF

• 标题: TP5_Delay_CF
• 标准依据: ISO 15765-2第6章（多帧通信协议）
• 测试方法: 发送一个多帧消息。将第一个连续帧延迟 Timeout Cr + 100ms。不期望任何响应。
  （此Test Case中DiVa Tseter表现异常，间隔时间不足N_Cr，可能为.cdd问题，暂不插入图片。）

Test CaseID-TP6: TP6_No_FC

• 标题: Test CaseID-TP6: TP6_No_FC
• 标准依据: ISO 15765-2第6章（多帧通信协议）
• 测试方法: Tester请求一项服务，其响应需要多个响应帧。不要发送流量控制（FC）。不期望任何响应。

Test CaseID-TP7: TP7_Delay_FC

• 标题: TP7_Delay_FC
• 标准依据: ISO 15765-2第6章（多帧通信协议）
• 测试方法: Tester请求一项服务，其响应需要多个响应帧。将所需的流量控制（FC）延迟 Timeout Bs + 100ms。期待 ECU 取消响应。
  （此Test Case中DiVa Tseter表现异常，间隔时间不足N_Bs，暂不插入图片。）

Test CaseID-TP8: TP8_Additional_FC

• 标题: TP8_Additional_FC
• 标准依据: ISO 15765-2第6章（多帧通信协议）
• 测试方法: Tester请求一项服务，其响应需要多个响应帧。测试仪发送两个流量控制（FC）帧，而不是一个。期望 ECU 响应。

Test CaseID-TP9: TP9_Check_Timeout_Bs

• 标题: TP9_Check_Timeout_Bs
• 标准依据: /
• 测试方法: Tester发送一个分段请求，以检查是否在 Timeout Bs 时间内收到ECU的流量控制（Flow Control）帧。期待ECU在N_Bs时间内发出流控帧。

Test CaseID-TP10: TP10_Check_Timeout_Cr

• 标题: TP10_Check_Timeout_Cr
• 标准依据: /
• 测试方法: Tester发送一个块大小（Blocksize）为0的流量控制（FC）帧，用于响应长度超过一个帧的响应。ECU必须在不等待另一个流量控制帧的情况下发送完整的响应。Tester验证每个连续帧（CF）是否在 Timeout Cr 时间内收到。

Test CaseID-TP11: TP11_STMin_Timing

• 标题: TP11_STMin_Timing
• 标准依据: /
• 测试方法: Tester发送一个流量控制帧（FC），用于应答长度超过一个帧的响应。ECU必须发送完整的响应。Tester验证连续帧（CF）之间的间隔时间不低于STMin时间。这将针对STMin值1, 10, 20, 30, 40, 50和60进行测试。

STMin = 1 测试数据

STMin = 60 测试数据

Test CaseID-TP12: TP12_Check_Valid_STMin

• 标题: TP12_Check_Valid_STMin
• 标准依据: /
• 测试方法: Tester发送一个分段请求，以检查ECU流量控制帧中的有效STMin时间。STMin时间值必须在 0x01-0x7F 或 0xF1-0xF9 范围内。

Test CaseID-TP13: TP13_Check_SF_Datalength

• 标题: TP13_Check_SF_Datalength
• 标准依据: /
• 测试方法: Tester发送一个请求，其响应为单帧（SF）响应。在收到响应后，检查单帧的长度是否在有效范围内。

Test CaseID-TP14: TP14_Check_FF_Datalength

• 标题: TP14_Check_FF_Datalength
• 标准依据: /
• 测试方法: Tester发送一个请求，其响应长度超过一个帧。在收到第一帧后，检查第一帧的数据长度是否在有效范围内。（有效范围：0x7 ~ 0xFFF）

Test CaseID-TP15: TP15_Response_Interrupted_By_SF

• 标题: TP15_Response_Interrupted_By_SF
• 标准依据: /
• 测试方法: Tester发送一个请求，其响应长度超过一个帧。在流量控制（FC）之后，Tester发送第二个诊断请求（单帧，SF）。ECU必须发送针对第一个请求的诊断响应，并且必须忽略第二个请求。

Test CaseID-TP16: TP16_Response_Interrupted_By_FF

• 标题: TP16_Response_Interrupted_By_FF
• 标准依据: /
• 测试方法: Tester发送一个请求，其响应长度超过一个帧。在发送流量控制（FC）之后，测试仪发送另一个诊断请求的首帧（FF）。ECU必须发送针对第一个请求的诊断响应，且不得对第一帧发送响应。

Test CaseID-TP17: TP17_Response_Interrupted_By_CF

• 标题: TP17_Response_Interrupted_By_CF
• 标准依据: /
• 测试方法: Tester发送一个请求，其响应长度超过一个帧。在流量控制（FC）之后，Tester发送一个连续帧（CF）。ECU必须发送针对第一个请求的诊断响应，且不得对连续帧发送响应。

Test CaseID-TP18: TP18_Response_Interrupted_By_FC

• 标题: TP18_Response_Interrupted_By_FC
• 标准依据: /
• 测试方法: Tester发送一个请求，其响应长度超过一个帧。在发送流量控制帧（FC）后，Tester收到第一个连续帧（CF），并发送另一个带有状态溢出（OVFLW）标志的流量控制帧。ECU必须发送针对第一个请求的诊断响应，并且不得对带有OVFLW标志的流量控制帧发送响应。

Test CaseID-TP19: TP19_Response_Interrupted_By_Unknown_Frame

• 标题: TP19_Response_Interrupted_By_Unknown_Frame
• 标准依据: /
• 测试方法: Tester发送一个请求，其响应长度超过一个帧。在发送流量控制帧（FC）帧后，Tester收到第一个连续帧（CF），并发送一个未知帧。ECU必须针对第一个请求发送诊断响应，且不得对未知帧发送响应。

Test CaseID-TP20: TP20_Request_Interrupted_By_SF

• 标题: TP20_Request_Interrupted_By_SF
• 标准依据: /
• 测试方法: Tester发送一个分段请求，在ECU发送流量控制帧（FC）之后，Tester插入另一个请求的单帧（SF）。ECU必须对第二个请求发送响应。

Test CaseID-TP21: TP21_Request_Interrupted_By_FF

• 标题: TP21_Request_Interrupted_By_FF
• 标准依据: /
• 测试方法: Tester发送一个分段请求的首帧（FF）。在收到ECU的流量控制帧（FC）之后，Tester发送另一个分段请求。ECU必须对第二个请求发送响应。

Test CaseID-TP22: TP22_Request_Interrupted_By_FC

• 标题: TP22_Request_Interrupted_By_FC
• 标准依据: /
• 测试方法: Tester发送一个分段请求，在收到ECU的流量控制帧（FC）之后，Tester插入了一个流量控制帧（FC）。之后，Tester继续发送剩余的连续帧（CF）。ECU应该正常回复诊断响应。

Test CaseID-TP23: TP23_Request_Interrupted_By_Unknown_Frame

• 标题: TP23_Request_Interrupted_By_Unknown_Frame
• 标准依据: /
• 测试方法: Tester发送一个分段请求的首帧（FF）。在收到ECU的流量控制帧（FC）之后，Tester插入一个未知帧。之后，Tester继续发送剩余的连续帧（CF）。ECU应该对整个请求发送一个诊断响应。

Test CaseID-TP24: TP24_Tester_Overflow

• 标题: TP24_Tester_Overflow
• 标准依据: /
• 测试方法: Tester发送一个带有溢出（Overflow）状态的流量控制帧（FC），用于响应长度超过一个帧的请求。在这种情况下，ECU不应发送任何连续帧（CF）。

Test CaseID-TP25: TP25_Blocksize_Check

• 标题: TP25_Blocksize_Check
• 标准依据: /
• 测试方法: Tester发送一个带有特殊块大小（Blocksize）的流量控制帧（FC），用于响应长度超过一个帧的请求。ECU必须根据流量控制帧中的块大小发送相应数量的连续帧（CF）。如果响应足够长，将分别检查块大小为1、8和20的情况。

BlockSize = 1
BlockSize = 8

Test CaseID-TP26: TP26_Blocksize_Null_Check

• 标题: TP26_Blocksize_Null_Check
• 标准依据: /
• 测试方法: Tester发送一个块大小（Blocksize）为0的流量控制帧（FC），用于响应长度超过一个帧的请求。ECU必须发送完整的响应。

Test CaseID-TP27: TP27_Incorrect_FlowStatus

• 标题: TP27_Incorrect_FlowStatus
• 标准依据: ISO 15765-2
• 测试方法: Tester发送一个带有无效状态值（3-15）的流量控制帧（FC），用于响应长度超过一个帧的请求。ECU不应发送任何响应。

Test CaseID-TP28: TP28_FlowStatus_Wait

• 标题: TP28_FlowStatus_Wait
• 标准依据: ISO 15765-2
• 测试方法: Tester发送一个带有等待（WT）状态值的流量控制帧（FC），用于响应长度超过一个帧的请求。ECU不应发送任何连续帧（CF）。在经过N_Bs超时时间后，Tester发送另一个带有继续发送（CTS）状态的流量控制帧（FC），ECU不应回复。Tester发送一个新的诊断请求，ECU需要响应。

请注意，此Test Case结果为Fail。此测试数据中，Tester没有等待N_Bs直接发送了FC.CTS 流控帧，推断为.cdd文件时间参数存在问题。

Test CaseID-TP29: TP29_Short_FC_DLC

• 标题: TP29_Short_FC_DLC
• 标准依据: ISO 15765-2
• 测试方法: Tester发送一个CAN-DLC过短的流量控制帧（FC），用于响应长度超过一个帧的请求。ECU不应发送任何连续帧（CF）。在该场景下，Tester随后发送一个新的请求，ECU必须对最后一个请求发送响应。

请注意，该测试数据错误，ECU没有响应Tester发出的[04] 22 00 00 00。

Test CaseID-TP30: TP30_Functional_FC

• 标题: TP30_Functional_FC
• 标准依据: ISO 15765-2
• 测试方法: Tester发送一个请求，其响应长度超过一个帧。在收到首帧（FF）后，Tester发送一个功能寻址的流量控制帧（FC）。ECU必须终止响应的发送。
  

Test CaseID-TP31: TP31_Incorrect_SF_DL

• 标题: TP31_Incorrect_SF_DL
• 标准依据: ISO 15765-2
• 测试方法: Tester发送一个单帧（SF），其数据长度不符合协议规定，SF_DL为0,8,9,10,11,12,13,14,15。ECU不应发送任何响应。
  

Test CaseID-TP32: TP32_Incorrect_CAN_DLC_SF

• 标题: TP32_Incorrect_CAN_DLC_SF
• 标准依据: ISO 15765-2
• 测试方法: Tester发送一个单帧（SF），其CAN-DLC小于或等于传输协议数据长度字段。ECU不应发送任何响应。
  

Test CaseID-TP33: TP33_Short_FF_DL

• 标题: TP33_Short_FF_DL
• 标准依据: ISO 15765-2
• 测试方法: 测试仪发送一个首帧（FF），其数据长度设置为0。根据ISO 15765-2协议，ECU不应发送任何响应。
  

Test CaseID-TP34: TP34_Incorrect_CAN_DLC_CF

• 标题: TP34_Incorrect_CAN_DLC_CF
• 标准依据: ISO 15765-2
• 测试方法: 在分段请求中，Tester发送一个连续帧（CF），其CAN-DLC小于或等于传输协议数据长度字段。ECU不应发送任何响应。
  

Test CaseID-TP35: TP35_Unknown_Frame

• 标题: TP35_Unknown_Frame
• 标准依据: ISO 15765-2
• 测试方法: Tester发送一个单帧（SF），其N_PCI类型大于3（即帧类型未知），这种帧被视为无效帧。在这种情况下，ECU不应发送任何响应。
  

Test CaseID-TP36: TP36_Functional_FF

• 标题: TP36_Functional_FF
• 标准依据: ISO 15765-2
• 测试方法: Tester发送一个功能寻址的首帧（FF）。ECU不应发送任何响应。
  

Test CaseID-TP37: TP37_Single_FF

• 标题: TP37_Single_FF
• 标准依据: ISO 15765-2
• 测试方法: Tester发送一个不完整的诊断请求，仅包含首帧（FF）而没有后续的连续帧（CF）时，ECU不应发送诊断响应。
  

Test CaseID-TP38: TP38_Unexpected_CF

• 标题: TP38_Unexpected_CF
• 标准依据: ISO 15765-2
• 测试方法: Tester发送一个单独的连续帧（CF）。ECU不应发送任何响应。
  

Test CaseID-TP39: TP39_Unexpected_FC

• 标题: TP39_Unexpected_FC
• 标准依据: ISO 15765-2
• 测试方法: Tester发送一个单独的连续帧（CF）。ECU不应发送任何响应。
  
  2025-04-29 完成

---

Format

1.1 InvalidRequestMessageLength

此测试章节测试思路为Tester构造无效长度的诊断请求报文，期待DUT回复NRC13（报文长度错误）。具体无效请求报文的构造分为3种：

情况一：MessageTooLong（请求报文过长）

• 构造方法：在正常UDS请求后面增加1个字节的0x00，长度字段覆盖此0x00；
• 测试范围：基本所有在CANDiVa工程生成时勾选的服务、DID均能测试此用例。
  • 切换到默认会话模式
  • 切换到扩展诊断会话模式
  • 切换到编程会话模式
  • 根据DID读取数据
  • 根据DID写数据
  • 安全访问_RequestSeed
  • 安全访问_SendKey
  • 通信控制_EnableRxAndTx
  • 通信控制_EnableRxAndDisableTx
  • 通信控制_DisableRxAndEnableTx
  • 通信控制_DisableRxAndDisableTx
  • 使用间接写数据发送
  • 通信控制_消息控制
  • 诊断仪下位复位
  • ECU复位_HardReset
  • ECU复位_KeyOffOnReset
  • ECU复位_SoftwareReset
  • 例程控制_StartRoutine
  • 例程控制_StopRoutine
  • 例程控制_RequestRoutineResults
  • 查询故障信息_ReportNumberOfDTCByStatusMask
  • 查询故障信息_ReportDTCByStatusMask
  • 查询故障信息_ReportDTCSnapshotRecordByDTCNumber
  • 查询故障信息_ReportDTCExtendedDataRecordByDTCNumber
  • 查询故障信息_ReportSupportedDTCs
  • 控制设备
  • 控制DTC设置_ON
  • 控制DTC设置_OFF
• 常见问题：如2E服务，常见回复NRC31（请求超出范围），CANDiVa测试报告会提示Warning（也可根据自身需求在Test Configuration - Tests - Response Checks中设置判断标准）。
  

情况二：MessageTooShort（请求报文过短）

• 构造方法：在正常UDS请求基础上，末尾减少一个字节，相应的UDS长度字段也减1；
• 测试范围：基本所有在CANDiVa工程生成时勾选的服务、DID均能测试此用例。其中DID不包含22读取，即保证DID完整，不会出现单字节DID的情况；
  • 切换到默认会话模式
  • 安全访问_SendKey
  • 输入输出控制
  • 根据DID周期读取数据
  • 例程控制_StartRoutine
  • 例程控制_StopRoutine
  • 例程控制_RequestRoutineResults
  • 通信控制_EnableRxAndTx
  • 通信控制_EnableRxAndDisableTx
  • 通信控制_DisableRxAndEnbleTx
  • 通信控制_DisableRxAndDisableTx
  • 读取故障码信息_ReportNumberOfDTCByStatusMask
  • 读取故障码信息_ReportDTCByStatusMask
  • 读取故障码信息_ReportDTCSnapshotRecordByDTCNumber
  • 读取故障码信息_ReportDTCExtendedDataRecordByDTCNumber
  • 清除故障码信息
• 常见问题：如2E服务，常见回复NRC31（请求超出范围），CANDiVa测试报告会提示Warning。
  

情况三：SidOnly（仅包含服务ID）

• 构造方法：仅使用服务ID，不使用子服务和后续负载；
• 测试范围：基本所有在CANDiVa工程生成时勾选的服务能测试此用例；
  • 诊断会话控制
  • 根据DID读取数据
  • 根据DID写数据
  • 安全访问
  • 输入输出控制
  • 根据DID周期读取数据
  • 例程控制
  • 通信控制
  • ECU复位
  • 读取故障信息
  • 清除故障信息
  • 故障诊断DTC设置
  • 诊断仪在线
• 常见问题：待补充。
  

1.5 PositiveResponseSuppressionBit

此测试章节测试肯定响应抑制位，包含以下几种测试情况：

情况一：有效请求测试

有效请求测试思路：Tester构造正确的诊断请求报文（肯定响应抑制位置位），期待DUT不回复。

• 构造方法：Tester构造正确的诊断请求报文，肯定响应抑制位置位；
• 测试范围：cdd文件中支持肯定响应抑制位的服务；
• 常见问题：DUT回复NRC78（等待响应）时，CANDiVa测试报告会提示Warning。
  

情况二：无效请求测试

无效请求测试思路：Tester构造错误的诊断请求报文（如长度不符合预期），期待DUT回复否定响应。

• 构造方法：Tester构造正确的诊断请求报文，肯定响应抑制位置位；
• 测试范围：cdd文件中支持肯定响应抑制位的服务；
• 常见问题：无。
  

1.6 MultipleResponse

此章节测试Periodic DID和Dynamically Define Periodic DID，Tester构造2A报文请求报文，期待DUT回复肯定响应。
说明：由于目前没有正确开发的cdd的文件，不清楚此部分测试用例是否会测试UUDT报文的周期发送、停发、周期大小等内容。待有测试条件后进行补充。

2025-06-10 完

---