今天的工作任务是验证某个项目的诊断协议问题。涉及到的是ISO 14229协议相关的知识点。
在来目前这家公司之前，我是没有车载测试相关的经验的，所以这个对我来说也是全新的挑战；虽然之前已经看过规范，但是还没有真正的进入项目实战过，今天协助验证问题，边学习，边记录重点咯。
几个典型的场景：
问题1：编程会话下的种子为固定值
步骤
1）10 03 -进入扩展会话
2）10 02 -进入编程会话
3）27 03 -编程会话解锁（前提已正确添加dll解锁文件）
4）重复步骤1、2、3
对比两次操作得到的 seed值
期望结果：两次的seed值不一致
相关知识点：
UDS 10服务、27服务
seed随机数生成原理
问题2：错误计数器为2时进入编程会话后连续请求三次种子时回复正响应
步骤：
1）扩展会话下连续请求种子或发送错误密钥使DUT进入delaytime
10 02
27 03-(连续请求4次)
2）等待10s
3）10 02 -进入编程会话
4）27 03
5）27 03
6）27 03
期望结果：
4）第五次请求种子时DUT回复NRC37
5）DUT回复正响应
6）DUT回复NRC37
知识点：
UDS 27服务 Delay time control和正确NRC
failure counter：3（错误计数器）
delaytime：10s
NRC:35 (第一次错误请求)、
36(第二次错误请求)、
37（大于等于3次错误请求)
问题3：发送STmin无效的流控帧，DUT响应的连续帧间隔
步骤：
1）请求多帧
2）DUT响应首帧
3）仿真发送Stmin无效（0xFF）的流控帧
-
检测DUT的多帧响应间隔
符合条件的DID
实际操作步骤需要写个小脚本执行，如下截图：
期望结果：
4.DUT的多帧响应间隔应大于127ms
实际结果：81ms
知识点：多帧的知识，STmin取值范围
知识点总结
27服务-总结
1）27解锁服务，请求错误计数器和超时时间验证
2）请求seed 随机数，每次生成的seed要不一致
3）要结合上下电操作，11 01 复位操作和会话切换，验证27服务解锁功能的实现
单帧传输和多帧传输-总结
单帧数据传输和接收：
举例：10服务下：
02 10 02 xx xx xx xx xx
02中的0代表网络层单帧SF，2代表 数据域有2个字节；10是SID，02是子功能
多帧数据传输和接收：
举例：
数据发送： 06 19 04 00 01 00 00 00
0 代表单帧，所以6代表发送的数据中含有6个字节，
数据反馈：
10 1E 59 04 00 01 00 27 --10中 1代表连续帧的首帧；0 1E 代表连续帧的长度为 30个字节
30 00 00 00 00 00 00 00 --30 代表连续帧的流控制帧
21 00 0B FF FF FF FF FF --21，22 ，23，24 中2代表连续帧 1，2，3，4代表连续帧的第几帧
22 FF FF FF FF FF FF FF
23 FF FF FF FF FF FF FF
24 FF FF FF AA AA AA AA --AA为填充位
FS流控制帧，有三种状态：继续发送0、保持等待1、数据溢出2（FC Byte1的bit0-3）
BS规定发送端允许持续传输连续帧数目的最大值（0~255）(FC Byte2)
STmin限定连续帧相互之间所允许的最小时间间隔（FC Byte3）
