车载诊断之Session（会话模式）汇总由于自己最近在做诊断会话模式内容的测试，又详细了复盘了该方面的内容，在此做一个简单的汇总。诊断会话模式是车载诊断范畴较为重要的三个状态机（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恢复至默认设置状态。以上四点都可以在测试时，特别关注。
|
|
|
