前言

上回說到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最后一米技術”的獨特優勢。