结合实例讲解UDS诊断中的—会话Session的切换

1、基础知识

1.1、常见的几种会话

1.2 会话之间的跳转

这里跳转，我们暂时不关注 10 04 会话和其他会话之间的关系

从这张图中可以读取很多信息和注意事项

注意点1：会话跳转顺序，10 01 default会话不能直接跳转到10 02 Programming会话和10 06会话中间需要先经过 10 03 Extened会话。

注意点2：Extened会话和Programming会话之间的跳转关系，只能由10 03-》10 02 ，注意只能是单向跳转。

注意点3：10 03《-》10 06之间可以相互跳转。

注意点4：任何非默认会话状态下，都可以通过10 01指令回到 Default Session中去。

注意点5：任何会话状态下都可以，再次对应的指令，重新进入相同的会话状态，如图中Default会话可以通过10 01再次进入efault会话。

注意点6：任何会话状态下，都可以使用复位服务（11 01）和（11 03）再次回到default 会话中。

1.3 区分几种会话的目的 

      做过实际项目的同学都知道，UDS诊断协议也就是ISO14229,之所以要花费精力来将会话等级做出划分，本质上是一种安全机制，配合0x27服务来实现。

        这种会话等级划分机制，保证了，那些服务只有在特定会话模式下，才能被使用，如0x34、0x35、0x36、0x37服务，只能在10 02编程会话下，才能使用。而进入编程会话前，还需要执行0x27安全解锁服务。这种机制下，就确保了MCU内的程序不会被恶意篡改。

2 会话跳转和BootLoad、APP之间的联系

1. 大家可以从Start中开始看，很多同学一看到外部重编程请求，这个判断语句时，就开始不了解是什么意思了，可以暂时理解为一个信号标志位，至于这个标志位如何触发=1，我们看到后面就明白了。

为了方便大家和自己的理解，我们按照实际项目测试中，操作步骤，分解开来看这张图，如下图

步骤1：

       通常我们KL30 和KL31(也就是地线)，连接到被测样件DUT上，然后KL15上电，启动重启。重启先执行一部分初始化过程，初始化后，进入判断“外部重编程请求”，此时我们没有任何操作，外部重编程请求可以看作=0。

步骤2：

      流程流转到，判断应用程序是否有效 ，（也就是我们有没有把APP烧录进去MCU中），此处可以理解为，当MCU中的FLASH中存在APP时，存在一个APP_In_Flash_Flag 标志位=1。然后延时20ms。

步骤3：

当20ms延时结束时，这时才会真的进入 App的Default模式下

步骤4：我们单独来看进入APP默认会话后的流程

   步骤4：如何进入Programing Session 会话，此步骤又可以划分为，另外几个不同的步骤

    步骤4.1 ：可以执行会话之间的转换，10 01 -10 03之间的相互转换

   步骤4.2：在拓展会话中，接收到10 02 指令后，并没有直接进入编程会话模式，而是“置外部重编程请求=01”，然后执行重启操作。哈哈！！是不是有点突破了以往的认知。

  步骤4.3：执行重启操作后，流程其实就是按照上图的步骤执行，

 步骤4.4 ：执行完初始化后，就开始检查“外部重编程条件”，这时，在步骤4.2中，我们已经将““置外部重编程请求=01”，所以流程直接跳转到编程会话 BootLoad Session

步骤5，编程会话Programing Session 如何跳转到 默认会话

     

  

          步骤 5.1 编程会话状态下，发送 10 01指令、或复位指令（11 01 或 11 03 ）、或 S3Service（一般设置为5000ms左右）超时，就会退出10 02 编程会话模式。和步骤4中进入10 02 编程会话相似。并不能直接跳！！

        步骤5.2 先“重设外部重编程标志”，这里更具体的解释：“将步骤4.2中的外部重编程标志位取反操作”，因为步骤4.2，将外部重编程标志=1，取反后=0。

       步骤5.3 然后执行重启操作，流程就跳转到最上面，初始化后“判断外部重编程请求”，步骤5.2中已经说明了，该标致位=00。

     步骤5.4 然后依次检查APP程序是否有效，判断APP有效后，延时20ms，延时时间>20ms后，才会进入 10 01 Default会话模式。

步骤6：如下图，这图中标注得2处，存在一个很特殊的点，也就是在2处，延时20ms时间中，如果此时接收到指令 10 03 就会立即进入BootLoad下的拓展会话模式。这一点也是特殊，至于为什么要这样设计暂时还不知道！！

步骤6中：总结，如果存在APP优先进入APP的默认会话，没有APP，才会进入Bootload的默认会话

 

 步骤7：0x11复位或超时情况下，是如何再次进入10 01默认会话的。

如下图，不过图中并没有标识处APP模式中，通过0x11复位或超时，是如何返回默认会话的，我单独在图中标注了出来

 3、结合实例说明会话切换对各种不同服务的影响

状态转换 1（从默认会话到默认会话）：

当控制器在默认会话模式下，测试设备请求启动默 认会话时，控制器应该完整的重新初始化默认会话。 在激活的会话期间，控制器应重置所有激活/启动/更改的设置/控制。这不包括编入非易失性存储器的长期变化。

      实例解释1、如2F F0 01是控制大灯继电器闭合开启的指令，（假设2F服务在默认会话下，有效），此时如果我们再次执行 10 01 指令，或 11 01、1103复位指令。那2F指令将会无效，需要重新激活。

      实例解释2、“这不包括编入非易失性存储器的长期变化”这句话，又该怎么解释！如2E F1 90 这个指令，是写入车辆识别码。此信息是需要写入，非易失性存储器。只要写入成功后，复位或重新激活默认会话，也还是保持上一次写入的值。

状态转换 2（从默认会话到非默认会话）：

当控制器从默认会话转换到非默认会话时，控制 器只应停止在默认会话期间通过 ResponseOnEvent（0x86）服务在控制器中配置的事件（类似 stopResponseOnEvent）。

      实例解释： 实际项目中，0x86服务其实很少见！也就是说，默认会话中执行的任何服务，在转换到非默认会话中，任然保持！！
状态转换 3（从非默认会话到非默认会话）：

当控制器从非默认会话转换到非默认会话时（包括当前激活的诊断会话），控制器应（重新）初始化诊断会话，这意味着：
    (1)应该停止通过 ResponseOnEvent（0x86）服务在控制器中配置的每个事件。
    (2)安全性应重新锁定。 请注意，安全访问的锁定应将任何依赖于安全访问的激活诊断功能重置为未锁定状态（例如，激活 inputOutputControl 的一个 DID）。

     实例解释：如10 03 模式下的2E服务，是需要27 01/02解锁后，才能执行写入操作，这里注意一点（27 01/02 /03xxxxx）等服务都是没有失效限制的，"安全性重新锁定"的意思是，如果我们重新执行 10 03指令，此时如果想执行2E服务，就必须先执行27解锁服务。
    (3)应保持新会话中支持并且不依赖安全访问的所有其他激活的诊断功能。 例如，任何已配置的定期调度器在转换时都应保持激活状态从一个非默认会话到另一个或相同的非默认会话，并且不会影响 CommunicationControl（0x28）和 ControlDTCSetting（0x85）服务的状态。就像刷写过程中，10 03 会话中使用0x28服务和0x85服务。然后转到10 02会话时，这两个服务依然要保持激活！！
状态转换 4（从非默认会话到默认会话）：

当控制器从默认会话以外的任何诊断会话转换 到默认会话时，控制器应通过 ResponseOnEvent（0x86）服务停止控制器中配置的每个事件， 并启用安全性。 任何其他在默认会话中不支持的诊断功能都将被终止。 例如，任何已配置的 周期性调度（0x2A）或输出控制（0x2F）应被禁用，并且 CommunicationControl 和 ControlDTCSetting 服务的 状态应被重置，这意味着正常通信在会话切换时，应重新启用默认会话。 在激活的会话期间， 控制器应重置所有激活/启动/更改的设置/控制。 这不包括编入非易失性存储器的长期变化。