UDS协议一致性测试之Service 27环境NRC 13、NRC 24优先级判断

本文探讨了UDS协议一致性测试中Service 27的环境下的NRC 13和NRC 24优先级判断问题。在特定测试步骤下,ECU应回复NRC 24,而非NRC 13,依据UDS协议的安全解锁状态转换示意图。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

周末咯!!!

预祝各位看官周末愉快,牙齿晒太阳哈。

今天闲聊下在进行UDS协议一致性测试时,Service 27测试背景下NRC 13/24优先级判断问题。

在实际一个车载控制器项目,首先OEM会提出该控制器的诊断需求规范(本文暂以诊断视角分析问题),对于测试端,会根据需求规范,提炼出测试规范。

测试的目的是验证控制器功能实现是否是按照需求规范定义的内容来实现的,当然这期间会有很多正向、逆向、各种非工况的测试。

当然对于测试而言,又区分很多内容:单元测试、集成测试、敏捷测试等等,不是本文重点,不过多讨论。

首先如下图UDS协议对于NRC判定策略的通用判断:

判断类别有:

  1. 强制类;

  2. 可选择类;

  3. OEM自定义

常规判断优先级如下:

首先是UDS协议中定义该Service的最小长度判断——NRC 13;

该服务是否支持所发送的Subfunction(子服务)——NRCA12;

该服务是否需要进行认证才可以执行——NRC34;

该服务的子服务在当前会话模式下是否支持——NRC 7E;

可选项中:

### 关于27号服务 (Security Access) 的NRC优先级 在ISO 14229标准中,定义了统一诊断服务(UDS),其中包括安全访问服务(Service ID: $27$)。对于任何诊断请求,如果发生错误,则会返回否定响应码(Negative Response Code, NRC)。关于NRC优先级,在ISO 14229-1:2013(E)中有明确规定[^1]。 #### 否定响应码优先级概述 当多个条件触发不同的NRC时,应按照预定义的优先级顺序选择一个NRC作为最终响应。以下是常见的NRC优先级列表: 1. **$0x11$: Condition Not Correct** 此NRC通常用于表示某些前置条件未满足,例如安全访问尚未完成。 2. **$0x12$: Sub-function Not Supported or Invalid Format** 如果子功能不被支持或者参数格式非法,则此NRC具有较高优先级。 3. **$0x13$: Request Out Of Range** 当请求的数据超出允许范围时,该NRC会被触发。 4. **$0x22$: Security Access Denied** 对于$27$服务而言,如果未能通过安全验证(即提供的密钥不匹配种子),则此NRC将被返回。它属于高优先级之一,因为它是针对安全访问的核心逻辑[^2]。 5. **$0x31$: Request Sequence Error** 若客户端发送的安全访问序列不符合协议规定(如跳过步骤或重复操作),则返回此NRC。 6. **其他通用NRC** 如$0x7F$(General Reject),其优先级较低,仅在无法归类至更具体类别时使用。 #### 特殊情况下的配置建议 在实现层面,ECU制造商可以根据实际需求调整部分细节,但需遵循标准框架内的约束。例如,某些场景可能需要自定义扩展以适应特殊应用环境。然而,默认情况下仍推荐采用上述标准化优先级设置[^3]。 ```python def get_nrc_priority(nrc_code): priority_map = { 0x11: "Condition Not Correct", 0x12: "Sub-function Not Supported or Invalid Format", 0x13: "Request Out Of Range", 0x22: "Security Access Denied", 0x31: "Request Sequence Error" } return priority_map.get(nrc_code, "Unknown NRC") # Example Usage print(get_nrc_priority(0x22)) # Output: Security Access Denied ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

汽车电子实验室

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值