点击蓝字 关注我们
传感器把温度、压力、位置变成比特流，主站则要在毫秒级周期里把这些比特流准时、完整地送进 PLC——这中间负责拆包、装车、验收、补货的，正是数据链路层（DL）。IO-Link Wireless 的 DL 层设计得相当讲究：既要扛住周期性过程数据（PD）的高频吞吐，又要给参数读写（ISDU）和诊断事件（Events）留出通道，还得在无线信道偶尔不靠谱时自己把丢的包补回来，这篇文章就把 DL 层从上到下拆开看一遍。
️ DL 层架构：DL-A 与 DL-B 各司其职
先给 DL 层画一张全景图，规范 6.1 明确了两条设计主线：DL 层被切成 DL-A 与 DL-B 两半——DL-A 承担数据调度与消息处理（对内的事务逻辑），DL-B 承担外部服务与各类 Handler（对外的业务接口）。与此同时，数据按类别分流：Process Data 走 Process Data handler，Event 与 ISDU 走各自的 Handler，而所有 Handler 最终都调用同一个 Message handler 去完成消息的收发，每个 Handler 都拥有独立的状态机。
DL 层还背着一个容易被忽略的职责：消息的错误检测与补救。规范原话是它要处理"内部的或 PL 上报的错误，并采取适当的补救措施（例如 retry）"——也就是说，丢包补发这件事，在 DL 层内部就闭环了，不需要应用层操心。
⚙️ 消息处理器：一条 W-Message 的编解码之旅
Message handler 是 DL-A 的核心，它回答一个很实际的问题：一条下行或上行负载里，各种消息按什么顺序装、每个字节怎么编码？
W-Master 侧的状态机规定了下行负载的放置顺序：先放 MasterCommands 和各时隙（Slot 0–7）的过程数据，再放各时隙的 Events，最后才放 ISDU——周期数据优先、非周期靠后的策略一目了然。W-Device 侧则相反，它负责在每个 W-Sub-cycle 被 PL 触发后，用子状态机 CreateMessage_8（Figure 51）按 PDIn → Event → ISDU 的固定顺序编译上行消息，同样把最要紧的进程数据排在前面。
消息的"信封"是控制字节（Control Octet）。下行 DLink 控制字节占 2 字节，由四段构成：Slot_N（目标时隙地址）＋ ChannelCode（通道编码）＋ FlowControl（流控）＋ DataLength（数据长度）。ChannelCode 决定这条消息走哪条通道：1=Process data、2=Process data INVALID、3=ISDU、4=EVENT、5=MasterCommand。上行 ULink 控制字节则被刻意压成 1 字节——ChannelCode 占 3 位、FlowControl 占 5 位，用精简开销换空中传输效率，数据长度干脆交给 FlowControl 顺带编码。
循环传输与状态管理：PDOut / PDIn 与 PDVALID / PDINVALID
过程数据是 DL 层的"主食"，规范给它配了四件服务：输出方向用 DL_PDOutputUpdate + DL_PDOutputTransport，输入方向用 DL_PDInputUpdate + DL_PDInputTransport，另外专门有一条 DL_Control 服务负责把过程数据标记为有效或无效——这就引出了 PDVALID / PDINVALID 这套状态语义。
细节在规范的A.9部分：PDIN_VALID 是自动生成的——W-Master 的 PDIn handler 每次成功收到 W-Device 发来的进程输入数据，就自动把该通道置为有效；反之，PDIN_INVALID 由 W-Device 应用主动发送，通过 AL/DL_Control 和 ULink 控制字节上报。输出方向完全对称：PDOUT_VALID 由 W-Device 收到有效输出数据时自动生成，PDOUT_INVALID 由 W-Master 应用下发。
这套机制还有一个隐藏价值：低功耗设备的按变化传输。数据只在发生变化时才交换，没变化就不发，一旦数据失效干脆停止发送、只发一个 INVALID 标记——省下来的空中时间，对电池供电的无线传感器意义重大。
非周期通道：Events 与 ISDU 的"顺风车"
周期数据之外，DL 层还养着两条非周期通道。ISDU（Indexed Service Data Unit） 负责参数读写这类按需服务，由 ISDU handler管理，编码方式与有线 IO-Link 保持一致；Events 负责诊断与事件上报，由 Event handler管理，每个事件带一个 EventQualifier，用 MODE（事件模式）＋ TYPE（类型：Notification / Warning / Error）＋ SOURCE（来源：主站或从站）＋ INSTANCE（实例） 四段共 8 位把事件描述得清清楚楚。
非周期数据的特点是"不定时、不定长"，它们与周期 PD 共用同一条传输管道，靠控制字节里的 ChannelCode 区分身份，靠 FlowControl 管理节奏——这正是下一节要讲的分段机制的用武之地。
分段传输与流控：长数据拆包上路
下行 32 字节、上行更精简的负载空间，装不下动辄几十上百字节的参数块或诊断数据——规范给出的答案是分段传输（Segmentation）：一条放不下的数据，拆成多个 W-Message 顺序发送，靠控制字节里的 FlowControl（FC）字段做流控计数。三种数据（PD、Event、ISDU）都走这套机制。
规范对于FlowControl 的语义定义得很清楚：0x08 START 标记一段数据的开始；0x00–0x07 COUNT 是段内计数器，从 1 递增、溢出回到 0；0x09 EOS 表示传输完成；0x0A ABORT 用于中止整个服务。最后一段的收尾方式因数据类型而异：PDOut 直接用 EOS 收尾，PDIn 用 PDataLength（1–14 字节） 收尾，而 Event/ISDU 则要单独再发一条不带数据的 EOS 消息，以确保重传场景下的数据一致性——这套细节，就是为了配合下面的重传机制。
重传控制：ACK / NACK 与 MaxRetry 的保底逻辑
无线信道不可能永远干净，DL 层的保底逻辑是一套确认 + 重发的组合拳。W-Master 的物理层收到有效上行包时，为对应时隙生成 ACK 位；W-Device 收到发给自己的有效下行数据时同样生成 ACK；反之，没收到确认、包丢失或 CRC 校验失败，就产生 NACK（ACK 位 = 0）。下行 ACK 是 8 位字段，每一位对应一个时隙的 W-Device，一次就能确认整条 W-Track。
拿到 NACK 之后怎么办？发送方要把最后一条 W-Message 连同最后一个 FlowCtrl 值原样重发；接收方如果发现新收到的 FlowCtrl 与上一次相同，就拒绝旧段、采用新段——之所以要这么设计，是因为确认包本身也可能在空中损坏，接收方可能"其实收到了数据但 ACK 丢了"，重发时必须保证两端对"当前段"的理解一致。
重试不是无限的。MaxRetry就是那条上限：从 PDOut handler 状态机里的 cycle_count = MaxRetries && PDOUT_INCOMPLETE 转移可以看出，重试耗尽仍未传完，就会向应用层上报故障；规范还专门画过 LQI（链路质量）与 PER（误包率）在不同 MaxRetry 下的关系曲线——重试次数越多，同样链路质量下能守住的可靠性就越高，但代价是占用更多子周期带宽，这是一个需要工程权衡的参数。
✅ 写在最后
把 DL 层的设计哲学浓缩成一句话：用 DL-A / DL-B 的分层把调度逻辑与业务处理分开，用固定优先级把周期数据稳稳托底，用分段 + 流控把长数据安全拆装，用 ACK/NACK + MaxRetry 把无线的不确定兜住。 每一层都朴素，叠在一起就是工业无线通信里那种"把意外提前算进去"的从容。
关注我们 阅读更多好文