[行业规范] 车载诊断之诊断会话模式汇总

[复制链接]
查看1298 | 回复0 | 2022-5-3 13:29:28 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?立即注册 |

x
由于自己最近在做诊断会话模式内容的测试,又详细复盘了该方面的内容,在此做一个简单的汇总。

诊断会话模式是车载诊断范畴较为重要的三个状态机(ISO 2020版 UDS协议更新了一个新的Service 29安全认证,因此现在是三个状态机):
  • 车载诊断会话模式(Service 10);
  • 车载诊断安全访问(Service 27);
  • 车载诊断安全认证(Service 29).
每一个状态机对于车载诊断范畴的诊断服务都有相应的影响,都是作为服务执行的Precondition存在。本文简单的从诊断需求规范、功能实现、测试三个方向汇总。
car-3866121.jpg
诊断需求规范
在OEM诊断需求规范中,基于ISO 14229协议明确定义自身需要的诊断会话模式,在协议中关于Session子服务有明确定义:

需要注意的协议给与了自定义的空间,给用户来自定义自身需求的诊断会话模式。比如以往项目中我遇到的主机厂会话模式,该模式下所有的诊断服务都不需要解锁,可以执行任何服务,这样方便调试。因此用户可以充分利用该方面内容。
在协议中已定义了常用的三个会话模式:默认会话模式、扩展会话模式、编程会话模式。诊断服务执行的前提条件就是通过诊断会话模式区分执行权限。不同的服务在不同的诊断会话模式执行,如下示意图:
9ecd45c9-bba8-48c7-8d6f-4c8bea216613.png

  • 默认会话模式只支持Service 22,用于读取车身相关信息(软件版本号、硬件版本号、ECU电压电流等);
  • 扩展会话模式支持的服务就相对多些,除了支持Service 22外还支持Service 2E/2F等;
  • 编程会话模式意味着当前状态是在Bootloader模式下,可以在该模式实现对ECU的UDS Software update。

对于诊断会话模式状态转换(如上示意图),一上电ECU当前必处于默认会话模式,当需要其他会话模式时,执行对应子服务实现跳转。ECU为防止自身一直处于较高级会话模式,会定义S3 时间参数,当该段时间没有收到任何诊断请求,会强制让ECU从非默认会话模式跳转到默认会话模式。
dff16832-a5ad-4244-866a-ef7dc7f790a7.png

如上内容(支持的诊断会话模式、诊断服务的执行权限等)都会在OEM诊断需求规范中定义,形成企业规范后,后续会释放给Supplier做功能实现。

诊断功能实现
行业内关于功能实现做法也分为不同策略:
  • 纯手动编写诊断功能代码,实现对诊断服务、DTC监控、DID信息读取和协议等操作,但鉴于稳定性较差,已慢慢不再采用(当初在测试这方面的功能时,问题复现把我折磨的欲仙欲死);
  • 通过加载诊断数据库和通信数据库,配置自动生成关于诊断的软件协议栈,如自己当初项目经验,是使用Vector的CANbedded协议栈(配置工具是Geny),需要导入的是CDD诊断数据库和dbc通信数据库。该框架下模块功能较为简单(对比AUTOSAR),从底层Driver,到CAN TP传输以及上层Application。框架示意图如下:
csm_CANbedded_Layer_Graphics_7ab58c501d.png

  • 最后是AUTOSAR框架下诊断功能实现,因为AUTOSAR框架是按照模块进行划分,对于车载诊断模块主要关心是DCM/DEM/FIM。作为一个完整的诊断数据链路条(暂且以车载CAN总线为例),需要从CAN Driver-> CAN IF -> CAN TP -> Pdur -> DCM/DEM -> RTE(与应用层交互)。相比第二种solution解决方案,车载诊断功能实现需要交互的模块更多更为复杂。比如与网络管理、ComM、ECUM、RTE等,交互场景更多也更为复杂。
图片.png

现阶段后两者使用较为普遍,尤其为最后一种。一般是基于诊断需求规范编辑诊断数据库(常见是ODX、CDD、MDX、ARXML等),将数据库导入配置工具,配置生成对应的协议栈,该软件框架已经形成,需要的是Supplier研发工程师将应用层的内容补充完整,诊断功能实现。诊断会话模式主要分布在DCM DSL功能模块中,该模块功能:
  • 处理诊断请求和响应数据流。
  • 管理诊断状态(会话状态和安全状态)。
  • 管理时间参数。
基于框架实现功能后,进行测试。

诊断功能测试
测试目的是验证功能实现是否是按照需求定义实现。本文主要分享诊断会话模式相关内容测试。
测试方向大致分为:
flowers-7135053.jpg
  • Valid Test/ Invalid Test
主要是关于诊断会话模式合法请求以及相关非法请求,比如请求报文格式过长或过短;
  • 诊断会话模式切换
主要是不同会话模式之间切换以及验证不同服务执行权限;
  • 会话模式切换带来的影响
这方面也是自己重点需要汇总,因为在ECU进行会话模式切换时,对ECU其他状态会造成相应的连带效应。
leaves-7153221.jpg
1、对于Service 27,若当前ECU处于解锁状态,ECU进行会话模式切换,ECU状态会从解锁状态跳转到锁住状态,其中包括一个非常典型的场景,比如ECU当前处于扩展会话模式并且是解锁状态,若Tester无意发送了 10 03请求,ECU当前还是处于扩展模式模式,但是ECU这时也需要从解锁状态跳转到锁住状态。因为ECU接受到会话模式请求后,都会进行初始化;
2、对于Service 28,若ECU处于非默认会话模式,并对ECU Communication模式进行设置,协议中有规定:ECU若进行非默认会话模式切换,Service 28设置状态不变化;若从非默认会话模式切换至默认会话模式,ECU需要将Service 28设置内容进行恢复至ECU默认设置状态;
3、对于Service 85,该服务是对ECU进行DTC功能管控,若ECU在非默认会话模式对ECU该功能做了非默认设置,在非默认会话模式切换无影响,若从非默认会话模式跳转到默认会话模式,ECU该功能设置项同样需要恢复至ECU默认状态;
4、对于Service 2F,该服务是对ECU I/O功能进行控制,类比上述描述,若在非默认会话模式之间切换,功能无影响;若从非默认会话模式切换至默认会话模式,需要将ECU恢复至默认设置状态。
以上四点都可以在测试时,特别关注。
"您的鼓励,是我前进的动力"
还没有人打赏,支持一下
车研会员,开心每一天!
您需要登录后才可以回帖 登录 | 立即注册 |

本版积分规则