上篇我们介绍了ISDU的典型编码格式和应用案例，本篇我们就来详细介绍下，ISDU的状态机，并把EVENT事件的逻辑，给大家好好解析下。
01 主站ISDU状态机如上图所示，ISDU的状态机的核心是请求，等待和响应。
如果主站请求的是DPP参数，即ISDU 0x00，0x01的参数，从AL层还是走的ISDU逻辑，但底层走了DL_Read/WriteParam的逻辑，即走的是Page通道。也就是好端端的ISDU愣是被它拆分了两个通道，增加了复杂性。
因为通常读写ISDU的命令都很长，一个循环放不下，都是多个循环来拆包，组包。具体的几个状态如下：
🌟T2：触发OD.req开始请求ISDU；
🌟T3：持续触发写请求，请求ISDU数据；
🌟T4：开始计时器（ISDUTime），查看是否会超时；
🌟T5：开始读请求，对之前写命令的读请求；
🌟T6：如果从站开始回应，则停止定时器；
🌟T7：持续的读取ISDU数据；
🌟T8：全部读取后，FlowCtrl为IDLE状态；
🌟T11：如果ISDU错误，则触发ISDUAbort命令，并向DL层确认ISDU错误；
🌟T13：通过OD.req来获取相关参数；
🌟T14：在正常PD交互中，采用IDLE的FlowCtrl进行OD交互
🌟T15：如果通信中断，消息处理通知DL_Mode处理模块，需要把ISDU模块去激活。
02 从站ISDU状态机从站ISDU的状态机和主站的状态很类似，请求、等待和响应三个状态缺一不可。
🔑T1：收到激活事件，从非激活状态迁移到Idle状态，等待ISDU的命令
🔑T2：开始接收ISDU数据，迁移状态到Request_2
🔑T3：持续接受数据，因为OD的数据大，而每次循环一般就传递1~2个OD数据，需要几个循环才能传输完，每次接收的OD数据需要缓存，等待接收完毕
🔑T4：所有ISDU接收完毕后，触发RecComplete事件，进入wait状态，该状态下尚未解析完成，如果主站查询数据，则回应busy
🔑T5：从站回应busy
🔑T6：从站做好准备，迁移状态到Response
🔑T7：等待主站的read命令，开始读取数据，调用OD.rsp来回应主站
🔑T8：发送完成，触发SendComplete事件，回到idle状态
🔑T9：接收到ISDUAbort命令
🔑T10：接收ISDUAbort命令
🔑T11：接收ISDUAbort命令
🔑T12：SM模块通知ISDU模块，去激活，回到非激活状态
🔑T13：收到ISDU Error消息，回到Idle状态
🔑T14：在Idle状态下，从站回应no service的命令
🔑T15：如果ISDU Error触发ISDU Abort
🔑T16：如果ISDU Error触发ISDU Abort
03 Event事件解析介绍完ISDU之后，我们来看一下事件。
事件有时候又称为诊断，它也是通过OD字段来传输，它的发起端虽然是主站来发起请求，但是最初的发起还是从站，从站会在每次传输时，在最后字节的一个bit置位，告诉主站自己有事件。
就好像小学生要回答问题，不能自己直接回答，得先举手示意🙋🏻♀️。这时候老师（主站）会问学生（从站），你有什么事情或者你想回答什么问题（事件）吗？这时候学生（从站）就会把自己的事情（事件）告诉老师（主站）。
Event在协议栈中以16 bit的EventCode存在，每个EventCode表示一个事件的定义；而所有的EventCode又可以分为三类：Error、Warning和Notification。
Error/Warning:简单归结为错误，故障类，比较严重，该类事件以出现/消失成对出现，如果出现了Error/Warning，需要维护人员去关注，直到它消失为止；
Notification：仅仅是通知，不是很严重，可能并不需要关注，它没有出现/消失这种机制，就是见到的SingleShot。
事件上报
如上图所示，上报事件通过查看从站的内存里的数据来上报，规范规定了一次性最大临时存6个事件，共占用18个字节，加上一个状态字节，共19字节。
事件的状态机
最后看一下事件的状态机，这个就比较简单了，主站状态机如下：
主站的状态机基本就是Idle和读事件，读完确认就结束了。
从站也很简单，就是触发事件，读取事件的时候，要冻结内存，不能让新事件写入内存，导致干扰。
结语好了，本篇总结了ISDU的状态机以及EVENT事件的业务逻辑，内容有点多，希望大家慢慢消化。
