睿远研究院丨IO-Link规范解读（十四）：DS模块详解

前言
 

上回说到PM模块，那么紧跟着的一定就是DS模块了。DS的全称是Data Storage。虽然DS是很多单词的缩写，在IO-Link领域可是比较神圣的一个模块，还有一个汽车品牌也是DS的缩写，可是“女神”的含义。

好了，我们今天就来好好揭开，这个DS模块的“神秘面纱”。

1

 DS的定义

数据存储（DS）机制使得从站设备参数在上层系统（如PLC程序或现场总线参数服务器）上能够一致且及时地进行缓存。

主站和从站之间的数据存储在IO-Link标准中进行了规定，而相邻的上层数据存储机制取决于各自的现场总线或系统。设备持有一组标准化的对象，提供有关数据存储的参数信息，例如内存大小要求以及数据存储机制的控制和状态信息。

数据存储参数集的修订，通过参数校验和来标识。

Data Storage机制和Block Parameter机制差不多，他们的检查机制相同。DS采用如上图的ISDU，包括DS的Command、状态、大小、checksum以及Index 列表。

说白了，DS就是参数持久化的一种方式，其实最简单的本地DS，就是设备把参数存储在自己的flash或者eeprom里，下次上电再恢复即可。

而IO-Link里讲的DS，则是把参数保存在从站的上层，也就是主站的FLASH或者再上面的PLC的存储里，就是希望在主站的该端口，无论插入什么样的设备，都能统一下发一致的数据，避免参数不一致的情况。

2

 DS的设备调试功能

IO-Link规范对“设备调试（Commissioning）”，分了2种：在线调试 和 离线调试。

系统参数（On-line commissioning）

过程：设备和 PLC 系统一起，在现场使用工程工具（如 TIA Portal、PACTware 等）进行配置和参数设置。

参数下载：用户通过工具给设备分配参数值，这些值被下载到设备中，成为激活参数（active parameters）。

数据存储：

 ·当系统发出 ParamDownloadStore 命令时，主站（Master）会将这些参数上传（复制）到其数据存储区（Data Storage）中。

 ·然后主站可以根据上层系统的特性进行备份操作。

适用于设备已经在现场安装好的场景。

离线调试（Off-site commissioning）

过程：使用如“USB-Master”等外部工具，以及设备的 IODD 文件，在非现场的地方（例如办公室），对设备进行配置和参数设置。

参数激活：通过工具完成配置和验证后，工具会设置 DS_UPLOAD_FLAG，标志该参数集为“已激活”。

安装后自动上传：

 ·当设备安装到现场并连接到主站后，主站会自动将这些参数上传到其数据存储中，完成备份。

说到USB-Master，强烈安利我们的USB-Master设备，这可是做传感器厂家的必备，童叟无欺，人见人爱，一设备在手，调试IO-Link不用愁。

再配合上位机软件，可以快速掌握IO- Link知识，调试IO-Link设备。

3

 DS的数据结构

我们在深究DS前，先看一下他的数据结构，其就是把ISDU的index、subindex、length和data挨个存储起来，另外还要加个头部，包括校验码，设备的ID等。

DS的头部：

4

 DS的状态机

DS是主站和从站配合完成的，从站状态机如下图所示，在启动后，基本就是在idle和dsactivity之间切换，说白了，就是负责ISDU的读取和写入。

下图是主站的DS状态机。

主站的DS状态机略微复杂，它的核心在Updown里；如果主站关闭了DS功能，则其就在off阶段，如果打开了ds，则会进入waitingonDSActivity等待DS的upload或者startup流程。

在整体的UpDownload阶段，分为检查，判断合法性，上传/下载，Ready几个阶段，任何一个阶段的错误都会直接进入DS Fault，并告知具体的错误原因。

看这几个阶段的具体功能：

在Upload和Download子过程中，就是不停的和从站进行交互，读取和写入ISDU。

5

 DS标识检查

我们知道，如果主站打开了DS模块，也就是端口模式配置了Manual模式，且指定了Backup & restore或者Restore模式之后就开始了DS流程。

在UpDownload2中，首先主站会检查自己存储的DS标识是否匹配从站的Vendor ID, Device ID;如果不匹配，就不会进入如下的流程。

那么这里的检查是怎么匹配的，这里就要回顾到SM模块的流程中，从下图看，有三种匹配方式：

1

NO_CHECK

顾名思义，不会检查任何ID，直接走后续流程

2

TYPE_COMP

只检查Vendor ID和Device ID，不检查SerialNumber，也就是只要是这一类的产品，都可以进行DS

3

IDENTICAL

最严格的，要检查SerialNumber，SerialNumber不对，也就走不到后续流程，但该选项在规范中已经明确不再要求实现了

6

 CheckMemSize

上述检查完成后，第二步就是CheckMemSize。

首先，主站发送 03 03 即查询DataStorageIndex的subindex 03，查询从站的DS大小，判断是否合适，规范规定不能超过2048字节，如果从站不支持DS模块，一定会回复一个0x8012，表示该subindex不存在。

主站收到0x8012，则会认为它的大小超过2048字节，就进入了DS fault流程，虽然结果是一致的，但总觉得这是规范是欠缺考虑的。如果从站不支持DS，是否应该直接通过某个标志告知主站，主站无需再进入DS流程即可。

查询Size之后，就开始检查是否要upload；首先发送03 02 ，查看State Property，如果bit7位为1，标识DS_UPLOAD_Flag 为true，同时模式为Upload & restore，就直接进入Upload流程。

如果模式不是Upload &resotre，是Restore模式，表示Upload被Disable了；又或者Upload的标志位没有被置位，则还需要进行DS Validity的验证。也就是看看主站本地的DS是否有效，前面所讲的，只有Upload标志位有效，同时Upload Enable，就强制直接进入Upload，其他的情况得等候DS Validity。

在DS Validity这个阶段，主站检查自己的DS数据是否有效，如果无效则也进入Upload流程；如果有效，则跳过Upload。

那么DS什么时候无效呢？比如DS里数据为空，就是无效；比如在Upload过程中，传输失败，那么DS也是无效。只要DS是无效的，就会走Upload流程。而DS有效，则主站认为不应该再上传从站的数据，这时候就要检查Checksum了。

7

Checksum

在检查Checksum流程，主站发送03 04查询Checksum，如果Checksum一致，表示主从的数据是一致的；如果Checksum不一致，则主站强行下载数据给从站，覆盖从站的ISDU。下载成功则进入DS ready，下载失败，则进入DS fault。

最后附上Upload和Download的流程。

结语  
 

好了，以上就是本期DS模块处理与检查流程的解析，DS作为IO-Link的关键功能，能够大幅度降低现场设备更换的难度，也是IO-Link作为“工业4.0最后一米技术”的独特优势。