CaaS架构：让整个工业网络成为一台虚拟 PLC

前言：一条产线更换产品时，为什么常常需要重新接线、重新分配控制器、重新配置通信？CaaS 从"设备---控制器---任务"的绑定关系入手，把控制程序分布式部署到网络交换机，并联合安排计算与通信，让工业控制以服务的形式提供给应用。

关键词： 工业互联网、TSN、PLC、网内计算、控制即服务、计算通信联合调度

文章目录

- [1. 论文信息与核心问题](#1. 论文信息与核心问题)
- [2. 为什么把控制任务放进交换机？](#2. 为什么把控制任务放进交换机？)
- [3. 系统结构：四个层次与软硬件分工](#3. 系统结构：四个层次与软硬件分工)
- [4. 第一个关键设计：把 PLC I/O 变成网络数据](#4. 第一个关键设计：把 PLC I/O 变成网络数据)
- - [4.1 从物理端口绑定到逻辑地址绑定](#4.1 从物理端口绑定到逻辑地址绑定)
  - [4.2 "可在任意位置控制"有工程前提](#4.2 “可在任意位置控制”有工程前提)
- [5. 第二个关键设计：把确定性延伸到计算内部](#5. 第二个关键设计：把确定性延伸到计算内部)
- [6. 第三个关键设计：计算与通信必须一起排程](#6. 第三个关键设计：计算与通信必须一起排程)
- - [6.1 为什么"先放任务，再排网络"不够？](#6.1 为什么“先放任务，再排网络”不够？)
  - [6.2 联合调度需要满足什么约束？](#6.2 联合调度需要满足什么约束？)
  - [6.3 重新配置并非完全不停机](#6.3 重新配置并非完全不停机)
- [7. 实验：时延下降来自哪些环节？](#7. 实验：时延下降来自哪些环节？)
- - [7.1 实验设置和比较对象](#7.1 实验设置和比较对象)
  - [7.2 主要结果](#7.2 主要结果)
  - [7.3 消融实验说明了什么？](#7.3 消融实验说明了什么？)
- [8. 独特贡献与尚未解决的问题](#8. 独特贡献与尚未解决的问题)
- [9. 对 TSN 与网内控制研究的启示](#9. 对 TSN 与网内控制研究的启示)
- 参考文献与图片来源

1. 论文信息与核心问题

项目	内容
英文标题	CaaS: Enabling Control-as-a-Service for Real-Time Industrial Networking
作者	Zheng Yang、Zeyu Wang、Xiaowu He、Yi Zhao、Fan Dang、Jiahang Wu、Hao Cao、Yunhao Liu、Qiang Ma
发表信息	IEEE Journal on Selected Areas in Communications，2025；所提供文件为已接收的作者版本
DOI	10.1109/JSAC.2025.3574598
研究对象	工业控制任务的分布式部署，以及计算与通信的端到端确定性
核心方案	可执行控制任务的 TSN 交换机 + 网络化 PLC I/O + 任务与流量联合调度

传统 PLC（可编程逻辑控制器）一般周期性地读取传感器、执行控制程序、更新执行器。它的可靠性已经在工业现场得到长期验证，但设备、I/O 接口和控制程序往往紧密绑定。

论文通过汽车玻璃制造场景指出，柔性生产需要频繁调整产品规格和工序。此时，控制关系的改变可能意味着重新接线、迁移程序甚至更换 PLC。CaaS 想解决的问题是：能否让应用只描述控制任务，由网络负责选择执行位置并保证执行时序？

图 1：传统控制系统与 CaaS 的对比，截自原文 Figure 1，PDF 第 2 页。左侧把控制逻辑绑定到具体 PLC；右侧由网络中的交换机承载控制任务。

图中"虚拟 PLC"是一个对应用暴露的整体抽象：底层存在多台交换机、多个处理器和多条链路，但上层可以把它们视为统一的控制资源。

2. 为什么把控制任务放进交换机？

如果只是把 PLC 程序迁移到远端服务器，虽然能改善集中管理，却会让控制回路经过更多通信与计算环节。服务器算得快，并不必然意味着执行器能准时收到结果。

CaaS 选择交换机，是因为它位于传感器与执行器之间的数据路径上。把任务放到合适的交换机，可以同时利用其转发能力和计算能力，并统一安排输入、计算、输出的时间。

一个控制任务可以理解为：

text 复制代码

传感器产生输入
    → 输入帧经过 TSN 网络
    → 指定交换机执行控制程序
    → 输出帧经过 TSN 网络
    → 执行器接收控制结果

不过，"交换机支持 TSN"和"交换机能够确定性执行控制程序"是两件事。TSN 主要约束网络传输，控制程序还可能遭遇 CPU 调度、内部数据搬运和时钟不一致造成的抖动。

3. 系统结构：四个层次与软硬件分工

图 2：CaaS 总体架构，截自原文 Figure 6，PDF 第 5 页。左侧是系统层次，右侧是单台交换机的软硬件结构。

从左侧自上而下看，系统包含四个层次：

层次	主要职责
应用层	提交工业控制任务
控制层	CNC 联合决定任务部署与通信时间表
计算与转发层	CaaS 交换机执行控制程序并转发数据
设备层	传感器提供输入，执行器接收输出

CNC 即集中式网络配置实体。它产生的调度不仅包含交换机的门控配置，还包含控制任务在哪里执行、何时执行。

论文使用 Xilinx ZYNQ-7000 SoC 实现交换机。其内部主要分成两部分：

PL（可编程逻辑）：实现交换结构、队列和门控、实时时钟、硬件时间戳等需要精确时序的功能。
PS（处理系统）：运行基于 OpenPLC 修改的控制运行时，以及时间同步算法、配置客户端等复杂逻辑。

这也是阅读本文时需要建立的硬件认识：控制程序主要由 PS 的 CPU 执行，PL 提供精确转发、计时与数据交换支持。CaaS 并不要求把所有控制程序都改写成 FPGA 电路。

4. 第一个关键设计：把 PLC I/O 变成网络数据

4.1 从物理端口绑定到逻辑地址绑定

传统 PLC 程序中，%IW0 可以表示某个输入字地址，%QX0.0 可以表示某个输出位地址。程序对地址进行读写，而硬件 I/O 层把它们关联到实际端子和设备。

CaaS 保留这类程序接口，但增加 Packetized PLC IO：把变量地址和数值封装进以太网帧，让网络承担原先由直接接线完成的数据交换。

图 3：Packetized PLC IO 的工作方式与帧格式，截自原文 Figures 8、9，PDF 第 6 页。图中温度值 67 与地址 %IW0 一起进入网络帧。

以温度控制为例，流程如下：

温度计将测量值和逻辑输入地址封装成数据帧。
帧的目标 MAC 地址指向当前执行该任务的交换机。
交换机解析变量地址，把输入值写入控制运行时。
控制程序在约定的时刻运行，产生新的输出变量。
输出地址和输出值再次封装成网络帧，发送到执行器。

任务迁移后，系统可以调整输入流目的地及调度配置，而无需让应用重新理解全部物理连线。

4.2 "可在任意位置控制"有工程前提

设备需要能够参与规定的数据封装和通信过程。论文明确提到，不支持 TSN 的设备可能需要转换器或封装器。因此，网络化 I/O 提供了设备解耦的基础，但既有产线仍需要处理接口适配问题。

5. 第二个关键设计：把确定性延伸到计算内部

可以把控制链路的时延概念性地分解为：

L = L_{\\mathrm{input}} + L_{\\mathrm{exchange,in}} * L_{\\mathrm{wait}} + L_{\\mathrm{compute}} * L_{\\mathrm{exchange,out}} + L_{\\mathrm{output}}.

这是本文用于解释的分解式。它提醒我们：即使网络输入和输出已经准时，中间的数据搬运、等待与计算仍然可能造成时序违约。

论文提出三项配套设计：

设计	解决的问题	实现思路
Dual DMA	控制 I/O 与元数据争用 PL---PS 通路	为控制数据和 CaaS 元数据配置独立 DMA 通道
Core Isolation	后台进程干扰控制程序	为控制运行时保留独立 CPU 核
Global-Time-Aware Execution（GTA）	控制执行时钟与网络时间表不一致	从 PL 的已同步 RTC 读取全局时间，并据此触发任务

三者的关系可以这样理解：DMA 保证数据交换更稳定，核隔离保证执行过程更稳定，GTA 保证开始执行的时刻与网络计划一致。

一个典型失效情形是：控制程序只晚完成几十微秒，却恰好错过预留发送窗口，于是等待下一周期。此时局部计算的小幅延迟，会放大成整个控制回路的较大延迟。

6. 第三个关键设计：计算与通信必须一起排程

6.1 为什么"先放任务，再排网络"不够？

假设两台交换机都能运行某个控制任务。第一台离传感器更近，第二台离执行器更近；同时，两台交换机的 CPU 空闲区间和链路占用情况也不同。

只看计算资源做出的任务部署决定，可能让后续通信无处安排；只选择最短通信距离，也可能撞上繁忙的计算时间段。

图 4：任务与流量共享一张全局时间表，截自原文 Figure 11，PDF 第 7 页。横轴为时间，不同行分别代表链路资源和交换机计算资源。

读图时，沿着"输入传输 → Task1 执行 → 输出传输"追踪颜色块即可。只有这三个阶段按依赖顺序连起来，才构成可用的控制服务。

6.2 联合调度需要满足什么约束？

论文把任务描述为：

j i = ( S i , D i , T i , P i , M D i ) , j_i=(S_i,D_i,T_i,P_i,MD_i), ji=(Si,Di,Ti,Pi,MDi),

其中， S i S_i Si 和 D i D_i Di 是输入、输出设备集合， T i T_i Ti 是执行时间， P i P_i Pi 是周期， M D i MD_i MDi 是最大允许时延。

模型同时决定任务执行位置、开始时间以及相关数据流的链路发送时刻，主要约束包括：

同一执行资源上的任务不能重叠。
同一链路上的帧传输不能冲突。
后一跳传输必须满足前一跳接收与转发所需的时间。
所有输入到齐后才能执行任务。
任务结束后才能发送输出。
从最早输入发出到最后输出到达，不能超过任务截止时间。

在找到可行解之外，还可以最小化所有任务的总时延：

min ⁡ ∑ i ( t i l a s t o u t p u t − t i f i r s t i n p u t ) . \min \sum_i \left(t_i^{\mathrm{last\ output}}-t_i^{\mathrm{first\ input}}\right). mini∑(tilast output−tifirst input).

原文使用 Z3 SMT 求解器实现该模型。一个需要保留的假设是：任务位置确定后，相关流按照模型规定的最短路径传输。因此，不宜把该方案描述为对所有可能路由进行无约束联合搜索。

6.3 重新配置并非完全不停机

原文的工作流程是先计算新调度，再暂停产线和任务、下发新配置，最后恢复执行。因此，CaaS 改善了重配置方式与资源解耦，但这份实现不能直接解释成已经支持无停顿的任务热迁移。

7. 实验：时延下降来自哪些环节？

7.1 实验设置和比较对象

论文使用三种测试床拓扑：A380 简化拓扑包含 9 台交换机和 8 个设备，Ring6 包含 6 台交换机和 6 个设备，Tree 包含 7 台交换机和 7 个设备。

主要实验中，任务周期为 33 ms，执行时间为 1 ms；每种拓扑进行 50 组实验，每个任务记录 1,000 个周期。这里的 jitter 定义为时延标准差。

基线同样实现了网络化 PLC I/O，但采用单 DMA、无核隔离和分两步调度；两个变体分别不支持或支持 GTA。因而下述提升对应这些实验基线，不能直接推广为相对于任意商用 PLC 的性能优势。

图 5：整体性能，截自原文 Figure 12，PDF 第 10 页。每一行对应一种拓扑，后三列依次是丢包率、平均时延和时延抖动的 CDF。抖动横轴为对数尺度。

7.2 主要结果

指标	原文报告结果	如何理解
平均时延	相对支持 GTA 的基线降低约 42%--45%	来自联合调度和更可靠的按表执行
A380 典型任务时延	CaaS 多数任务集中在约 1.31 ms	包括计算与通信，不能当成纯交换转发时延
丢包	CaaS 在这些实验中为 0	反映测试范围内没有发生相应的交付违约
抖动中位数：A380	4.6 μs；基线为 5.4 ms	约三个数量级差异
抖动中位数：Ring6	3.7 μs；基线为 5.6 ms	同上
抖动中位数：Tree	4.4 μs；基线为 5.2 ms	同上

特别注意丢包口径： 实验规定，当相关任务错过预定计算时间时，对应数据包会被丢弃。因此，无 GTA 基线出现丢包率为 1，表示它无法按调度要求交付，不应理解为物理链路完全不能传送以太网帧。实验观察到零丢包，也不等于对所有故障和负载给出无限期可靠性证明。

7.3 消融实验说明了什么？

图 6：双 DMA、核隔离和 GTA 的作用，截自原文 Figure 13，PDF 第 11 页。图中 CDF 没有达到 1 的部分可能对应被视为无穷大时延的丢弃样本，不能只看保留下来的快速样本。

去掉双 DMA：随着 PL---PS 额外流量增加，单 DMA 方案丢包率由 3.1% 增至 55.4%，而双 DMA 在该实验中保持零丢包。
去掉核隔离：随着后台 CPU 使用率上升，丢包率由 2.1% 增至 9.7%。
去掉 GTA：在专门保留所有包的实验中，时延分散到约 1--35 ms；启用 GTA 后集中在约 1.2 ms。

这些结果把原因落到了具体环节：网络内部的数据交换、CPU 干扰和时钟对齐，都能影响最终的控制时延。

8. 独特贡献与尚未解决的问题

CaaS 的贡献可以归纳为三个相互依赖的部分：统一的控制服务抽象、可确定性执行控制任务的交换机，以及同时考虑计算和网络资源的调度模型。单独拿走其中一部分，剩余部分未必仍能实现端到端控制保证。

论文也明确给出了边界：

大规模求解耗时高。 讨论部分指出，流数量达到 100 或更多时，SMT 求解可能需要数小时甚至数天。这是调度生成耗时，和运行阶段的毫秒级控制时延不同。
任务执行时间需要可建模。 实验采用给定的任务执行时间；实际部署需要评估运行时干扰与执行预算。
智能感知任务仍有额外挑战。 图像、点云传输和神经网络推理会带来新的计算与带宽需求，不能从梯形图任务的实验直接推导出同等性能。
故障处理需要继续设计。 把控制与网络能力集中到交换机上后，冗余、恢复和更新机制也需要纳入工程方案。

最后一项是本文从部署角度提出的延伸思考，不是原文已经完成的实验结论。

9. 对 TSN 与网内控制研究的启示

如果用这篇论文作为系统设计参考，最值得借鉴的是它的验证顺序：先建立网络化控制接口，再测量交换机内部的数据通路与计算抖动，然后建立计算通信联合时间表，最终验证传感器到执行器的完整链路。

对于调度研究，也应同时报告"找到时间表的效率"和"硬件执行时间表的效果"。前者解决重配置等待时间，后者解决控制回路的实时性；两者都优秀，控制即服务才更接近可部署的工业能力。

参考文献与图片来源

$1$ Zheng Yang et al. CaaS: Enabling Control-as-a-Service for Real-Time Industrial Networking . IEEE JSAC, 2025. DOI: 10.1109/JSAC.2025.3574598。本文以用户提供的作者版本 PDF 为依据。

$2$ 原文 Section III--VI：架构、交换机设计、联合调度及实现，PDF 第 4--9 页；Section VII--IX：评测与讨论，PDF 第 9--12 页。

本文使用的原图为 Figures 1、6、8、9、11、12、13，版权归原作者及相应权利方所有。图中实验曲线未修改；中文解释、时延分解式及工程启示为本文整理。