车载诊断之诊断会话模式汇总

Fuu

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

诊断会话模式是车载诊断范畴较为重要的三个状态机（ISO 2020版 UDS协议更新了一个新的Service 29安全认证，因此现在是三个状态机）：

• 车载诊断会话模式（Service 10）；
• 车载诊断安全访问（Service 27）；
• 车载诊断安全认证（Service 29）.
  

每一个状态机对于车载诊断范畴的诊断服务都有相应的影响，都是作为服务执行的Precondition存在。本文简单的从诊断需求规范、功能实现、测试三个方向汇总。

诊断需求规范
在OEM诊断需求规范中，基于ISO 14229协议明确定义自身需要的诊断会话模式，在协议中关于Session子服务有明确定义：

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

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

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


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

诊断功能实现
行业内关于功能实现做法也分为不同策略：

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

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

现阶段后两者使用较为普遍，尤其为最后一种。一般是基于诊断需求规范编辑诊断数据库（常见是ODX、CDD、MDX、ARXML等），将数据库导入配置工具，配置生成对应的协议栈，该软件框架已经形成，需要的是Supplier研发工程师将应用层的内容补充完整，诊断功能实现。诊断会话模式主要分布在DCM DSL功能模块中，该模块功能：

• 处理诊断请求和响应数据流。
• 管理诊断状态（会话状态和安全状态）。
• 管理时间参数。
  

基于框架实现功能后，进行测试。

诊断功能测试
测试目的是验证功能实现是否是按照需求定义实现。本文主要分享诊断会话模式相关内容测试。
测试方向大致分为：

• Valid Test/ Invalid Test
  

主要是关于诊断会话模式合法请求以及相关非法请求，比如请求报文格式过长或过短；

• 诊断会话模式切换
  

主要是不同会话模式之间切换以及验证不同服务执行权限；

• 会话模式切换带来的影响
  

这方面也是自己重点需要汇总，因为在ECU进行会话模式切换时，对ECU其他状态会造成相应的连带效应。

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恢复至默认设置状态。
以上四点都可以在测试时，特别关注。