睿远研究院丨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做了介绍，内容有点多，希望大家慢慢消化。