IO-Link ISDU状态机与EVENT事件详解
上篇我们介绍了ISDU的典型编码格式和应用案例，本篇我们就来详细介绍下，ISDU的状态机，并把EVENT事件的逻辑，给大家好好解析下。
1主站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模块去激活。
2 从站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
3 Event事件解析
介绍完ISDU之后，我们来看一下事件。
事件有时候又称为诊断，它也是通过OD字段来传输，它的发起端虽然是主站来发起请求，但是最初的发起还是从站，从站会在每次传输时，在最后字节的一个bit置位，告诉主站自己有事件。
就好像小学生要回答问题，不能自己直接回答，得先举手示意。这时候老师（主站）会问学生（从站），你有什么事情或者你想回答什么问题（事件）吗？这时候学生（从站）就会把自己的事情（事件）告诉老师（主站）。
Event在协议栈中以16 bit的EventCode存在，每个EventCode表示一个事件的定义；而所有的EventCode又可以分为三类：Error、Warning和Notification。
Error/Warning:简单归结为错误，故障类，比较严重，该类事件以出现/消失成对出现，如果出现了Error/Warning，需要维护人员去关注，直到它消失为止；
Notification：仅仅是通知，不是很严重，可能并不需要关注，它没有出现/消失这种机制，就是见到的SingleShot。
01事件上报
如上图所示，上报事件通过查看从站的内存里的数据来上报，规范规定了一次性最大临时存6个事件，共占用18个字节，加上一个状态字节，共19字节。
02事件的状态机
最后看一下事件的状态机，这个就比较简单了，主站状态机如下：
主站的状态机基本就是Idle和读事件，读完确认就结束了。
从站也很简单，就是触发事件，读取事件的时候，要冻结内存，不能让新事件写入内存，导致干扰。
4 应用层的OD模块状态机
前面提到的EVENT状态机和ISDU状态机，这俩都属于OD这个模块的内容，OD又分为数据链路层和应用层两块，下面我们就展开聊一下应用层的OD和EVENT部分。
下图先看一下主站应用层的OD模块：
从这个状态机，我们看到AL应用层的OD部分，仅仅包含了ISDU和DPP两方面。
对于index 00和01的读写，划归到DL Param部分，对于其他的划归于ISDU部分，当主站发起AL Service时，协议栈开始构建DL Service，根据index来确定是走左边，还是走右边。
当进入await状态时，不允许第二个AL Service来访问，否则就会被禁止，直接告知客户主站正忙。
再来看下从站AL的OD模块，如下图所示：
从站和主站类似，也有await状态；对于参数的读写分别进入await_AL_Write_rsp_1和await_AL_Read_rsp_2；而对于ISDU的读写，则进入Await_AL_RW_rsp_3。
四个状态如下：
5应用层的OD传输序列
那么主站和从站的ISDU和DPP是如何交互的呢？
01 ISDU的传输
主站APP发起读取ISDU参数（Index>1）指令；
主站AL层调用DL的DL_ISDUTransport_req函数
主站DL层把命令封装到消息中发送给从站
从站调用DL_ISDUTransport_ind函数对主站的ISDU读命令进行解析；
解析后上送给AL层进行数据查询
上层的App进行数据读取，返回给AL层并继而由物理层发给主站
主站接到从站的回应，解析报文，上送APP层。
02 DPP的传输
主站APP发起读取DPP参数（Inde≤1）指令；
主站AL层面调用DL的DL_ReadParam函数
主站DL层把命令封装到消息中发送给从站
从站调用DL_ReadParam函数对主站的DPP读命令进行解析；
解析后上送给AL层进行数据查询
上层的App进行数据读取，返回给AL并继而由物理层发给主站
主站接到从站的回应，解析报文，上送APP层
03 关于AL Abort
查询ISDU是有时间限制的，如果查询从站的ISDU没有在规定的时间内返回，则主站发送一个Abort命令，终止ISDU的查询。
6应用层的EVENT模块
AL应用层也有单独的Event处理机制，我们分别看一下主站AL Event和从站的AL Event。
01 主站AL EVENT
02从站AL EVENT
03事件上报过程
从站的App创建一个事件，并开始发送请求信息
该请求信息从AL传递到DL层，并把事件缓存到内存中
从站的AL激活EventTrigger服务，置位EventFlag
主站读取从站的EventFlag后，开始读取从站的StatusCode以及相关EventCode
主站把相关Event继续上报给网关，网关应用确认事件消息
主站把事件确认消息同步给从站，写入StatusCode信息，即清除事件标志，等待下一个事件的上报
结语
好了，本篇总结了ISDU的状态机和EVENT事件的业务逻辑，以及对AL应用层的OD和Event做了介绍，内容有点多，希望大家慢慢消化。
