IT/OT融合实战：软件PLC、TSN与AI如何重构控制层

1. 控制层正在发生什么：从"两层皮"到"一张网"

干了十几年自动化，我见过太多工厂里 IT 和 OT 各玩各的场面。IT 那边抱着虚拟化、容器、微服务，天天讲敏捷迭代；OT 这边守着 PLC、DCS、现场总线，一个逻辑改动要走三天审批。两边开会，IT 说 OT 太保守，OT 说 IT 不懂现场，最后项目卡在"最后 100 米"——数据从产线到机房这段路，谁都推不动。

这两年情况变了。软件 PLC、确定性网络、AI 进入控制层这三件事凑到一起，把原来那堵墙凿开了一个口子。我最近参与的几个改造项目，控制层的形态跟五年前完全不是一回事：PLC 跑在工控机的容器里，网络用 TSN 做时间同步，AI 模型直接挂在控制回路旁边做参数寻优。这不是概念演示，是已经在跑的产线。

这篇东西写给两类人看。一类是 OT 侧的工程师，你可能正在被要求"上云""接 MES""做数据采集"，但不知道控制层该怎么改；另一类是 IT 侧的开发或架构，你想把软件工程那套东西带进车间，但被现场总线和实时性要求劝退过。我会把这三块技术的核心逻辑、选型考量、实操步骤、踩过的坑都摊开讲，尽量让你看完能判断自己的项目适不适合动、怎么动。

先说清楚一个前提：IT/OT 融合不是把 IT 那套原样搬到 OT。控制层有它自己的物理约束——微秒级的抖动可能让伺服报警，网络丢一个包可能让机械手撞机。所以下面讲的所有方案，都是在这个约束下做的折中，不是纯 IT 视角的理想架构。

2. 软件 PLC：把控制逻辑从专用硬件里解放出来

2.1 软件 PLC 到底是什么，跟传统 PLC 差在哪

传统 PLC 是一台专用硬件，CPU、IO、通信口焊死在一块板子上，你买的是西门子、三菱、罗克韦尔的整机，编程用它们各自的软件，逻辑跑在它们的实时操作系统上。软件 PLC 是把这套运行时软件化，跑在通用 x86 工控机或者 ARM 边缘盒子上，IO 通过 EtherCAT、Profinet 这些实时总线外挂。

我最早接触软件 PLC 是 2018 年前后，那时候稳定性还不太行，跑个把月会莫名重启。现在情况好很多，主流方案在工业现场连续跑一两年不出问题的案例不少。它的核心价值有三个：算力可扩展（想加视觉、加 AI 推理，直接加 CPU 核或 GPU）、部署灵活（一套镜像推到一百台设备，配置用代码管理）、IT 生态打通（能直接调 Python 库、能接消息队列、能做 CI/CD）。

但代价也很明确。传统 PLC 的实时性是硬件保证的，扫描周期抖动通常在微秒级；软件 PLC 跑在通用 OS 上，如果不做实时补丁，抖动可能到毫秒级，对高速运动控制是致命的。所以软件 PLC 的选型，第一件事就是看它的实时方案。

2.2 实时性怎么保证：三种主流路线对比

软件 PLC 要跑实时，绕不开操作系统这一层。目前工程上能落地的路线就三条，我列个表对比一下。

我自己的项目里，PREEMPT_RT 用得最多。原因是生态成熟，Python、Docker、各种库都能直接用，调优资料也多。Xenomai 的实时性更好，但跟通用 Linux 的隔离做得太狠，很多库用不了，开发效率掉得厉害。

具体怎么配 PREEMPT_RT，核心是几件事：CPU 隔离（isolcpus把几个核专门留给实时任务）、中断亲和性绑定（把网卡中断绑到非实时核）、关闭影响抖动的内核特性（比如 CPU 频率调节、透明大页）。这些参数不是拍脑袋定的，要用cyclictest实测。我一般会跑 24 小时，看最大抖动，如果超过 100 微秒，就得回去查是哪个中断在捣乱。

提示：cyclictest 的-m -p 80 -i 1000 -h 400 -n -l 1000000这组参数是我常用的，能跑出比较真实的负载下抖动分布。别只看平均值，最大值才是决定能不能用的关键。

2.3 软件 PLC 的实操部署：从裸机到跑通第一个逻辑

我拿一个真实项目举例。客户要做一条包装线，要求 8 轴伺服同步，扫描周期 1 毫秒，抖动不超过 50 微秒。硬件选的是一台研华工控机，i7 十二代，8 核，32G 内存，带 Intel i210 网卡（这块网卡对 EtherCAT 友好）。

第一步是装系统。Ubuntu 22.04 打 PREEMPT_RT 补丁，或者直接用已经打好补丁的镜像。装完先别急着上 PLC 运行时，先做基础调优：

# 修改 grub，隔离 2-7 核给实时任务，0-1 核跑系统 GRUB_CMDLINE_LINUX="isolcpus=2-7 nohz_full=2-7 rcu_nocbs=2-7 \ intel_pstate=disable processor.max_cstate=1 intel_idle.max_cstate=0 \ transparent_hugepage=never"

这几行的意思分别是：把 2 到 7 核从调度器里摘出来，不让普通进程上去跑；关掉这些核上的时钟中断，减少干扰；关掉 CPU 频率调节和深度睡眠，避免唤醒延迟；关掉透明大页，避免内存管理带来的抖动。

第二步是绑中断。用lspci -v找到 EtherCAT 网卡的中断号，然后：

# 把网卡中断绑到 0 核，别让它打扰实时核 echo 1 > /proc/irq/<irq_num>/smp_affinity

第三步装 PLC 运行时。我用过 CODESYS Runtime、Beckhoff TwinCAT/BSD、还有开源的 OpenPLC。CODESYS 生态最全，支持 EtherCAT 主站，授权费按设备收；TwinCAT 性能最好但绑 Windows 或 BSD；OpenPLC 免费但功能弱，适合学习不适合产线。

装完运行时，配 EtherCAT 主站，扫从站，映射 IO。这一步跟传统 PLC 组态差不多，区别在于所有配置都是文件，可以进 Git。我习惯把整个运行时配置目录纳入版本管理，改一个参数就提交一次，出问题能回滚。

第四步是写逻辑。IEC 61131-3 的五种语言都支持，但我现在越来越多用ST 语言 + 外部 Python 脚本的组合。ST 写实时逻辑，Python 做非实时的数据处理、跟 MES 通信、跑 AI 推理。两者通过共享内存或本地 socket 通信，Python 崩了不影响 ST 跑。

2.4 软件 PLC 的坑：我踩过的几个

第一个坑是网卡选型。不是所有网卡都适合做 EtherCAT 主站，Realtek 的很多型号直接不行，Intel i210、i219 比较稳。我一开始图便宜用了块杂牌网卡，从站老是掉线，换了 i210 立刻好。

第二个坑是BIOS 设置。C-State、P-State、超线程、VT-d 这些选项都会影响抖动。我一般会关掉 C-State 和 P-State，超线程看情况——如果实时任务核数够，关掉更稳；如果不够，开着但要把实时任务绑到物理核上。

第三个坑是内存分配。实时任务的内存最好预分配，别在运行中动态申请。我见过一个项目，Python 脚本跑着跑着触发 GC，把实时核的缓存挤了，导致扫描周期抖动超标。后来把 Python 进程绑到非实时核，问题消失。

第四个坑是散热。工控机塞在电柜里，夏天温度能到 50 度以上，CPU 降频，抖动立刻上去。这个不是软件能解决的，得从电柜空调或者风扇下手。

3. 确定性网络：让数据准时到达，而不是"尽力而为"

3.1 为什么控制层需要确定性网络

传统以太网是"尽力而为"的，数据包什么时候到不确定，拥塞了就排队，排队久了就丢。这在办公网络没问题，但在控制层是灾难。一个运动控制指令晚到 1 毫秒，伺服可能就报警了；一个急停信号丢包，后果更严重。

传统方案是用现场总线，EtherCAT、Profinet IRT、Powerlink 这些，它们通过主从轮询、时间片划分来保证确定性。但现场总线的问题是带宽低、拓扑死、跟 IT 网络不通。你想在同一个网络上跑控制数据和视频流，现场总线做不到。

确定性网络（Detnet、TSN）就是来解决这个的。它在标准以太网上加了一套时间调度机制，让关键流量按预定的时间窗口发送，非关键流量填缝隙。这样一条线上既能跑控制，又能跑视觉、跑数据采集，不用拉两套网。

3.2 TSN 的核心机制：时间同步、调度、整形

TSN 不是单一技术，是一组 IEEE 802.1 标准的集合。控制层最关心的是三块：时间同步（802.1AS）、时间感知调度（802.1Qbv）、流量整形（802.1Qav）。

时间同步是基础。所有节点要有一个共同的时间基准，精度到纳秒级。802.1AS 是 gPTP 的工业版本，通过主时钟广播时间，从时钟逐级同步。我实测下来，普通交换机上能做到亚微秒级，专用 TSN 交换机上能到几十纳秒。

时间感知调度是核心。它把时间切成周期性的窗口，每个窗口分配给特定的流量队列。比如 1 毫秒周期里，前 200 微秒留给控制数据，中间 500 微秒留给视频，最后 300 微秒留给普通数据。交换机按这个时间表开门关门，控制数据永远有独占通道。

流量整形是补充。对于不能严格调度的流量，用信用整形（Credit-Based Shaper）限制它的突发，避免它挤占关键流量。

3.3 实操：搭一个 TSN 测试床

我去年搭过一个 TSN 测试床，用来验证一条视觉+运动混合的产线。硬件是三台 TSN 交换机（我用的是支持 802.1Qbv 的型号）、一台软 PLC 工控机、一台视觉相机、一台普通 IT 服务器。

第一步是配时间同步。选一台交换机做 grandmaster，其他设备做 slave。配置里要指定域号、同步周期、 announce 超时这些参数。同步周期我一般设 125 微秒，跟 EtherCAT 的分布式时钟对齐。

第二步是配流量分类。把控制数据打上 VLAN 优先级 7，视频流打 5，普通数据打 0。然后在交换机上配 Qbv 门控列表：

# 伪代码，实际配置看交换机厂商 GateControlList: - Time: 0us, Gates: [7:open, 5:closed, 0:closed] - Time: 200us, Gates: [7:closed, 5:open, 0:closed] - Time: 700us, Gates: [7:closed, 5:closed, 0:open] - Time: 1000us, Gates: [7:open, 5:closed, 0:closed]

这个列表的意思是：每个 1 毫秒周期，前 200 微秒只放控制数据，中间 500 微秒放视频，最后 300 微秒放普通数据。控制数据的窗口是独占的，视频和普通数据抢不到。

第三步是验证。用ping测延迟没用，要看抖动分布。我用的是tsn_listener这类工具，抓每个周期的到达时间，算最大偏差。实测下来，控制数据的抖动在 1 微秒以内，视频流在 100 微秒以内，普通数据在毫秒级但无所谓。

3.4 确定性网络的选型与部署注意事项

选交换机是第一道关。不是所有标"TSN"的交换机都支持 Qbv，有些只支持 Qav 或者只支持时间同步。买之前一定要确认支持 802.1Qbv，而且门控列表的粒度要够细（至少 8 个队列）。

第二道关是端设备支持。软 PLC 的网卡要支持硬件时间戳，不然同步精度上不去。我用的 i210 支持，但有些便宜的网卡不支持，同步误差能到几十微秒。

第三道关是配置复杂度。Qbv 的门控列表要跟控制周期严格对齐，配错了要么控制数据被挤，要么带宽浪费。我一般会先用仿真工具算一遍，再上实际设备。

注意：TSN 的时间同步对网络拓扑有要求，环形拓扑要做冗余的话，配置会复杂很多。如果产线规模不大，星型拓扑最省事。

还有一个容易被忽略的点：TSN 交换机的时间同步域要跟现场总线对齐。如果一边用 EtherCAT 的分布式时钟，一边用 gPTP，两个时间基准不一致，数据融合的时候会出问题。我的做法是让 gPTP 跟 EtherCAT 的参考时钟同步，或者干脆用同一个时钟源。

4. AI 进入控制层：从"事后分析"到"实时参与"

4.1 AI 在控制层的三种角色

AI 进控制层，不是让 AI 直接输出控制指令——那太危险了。目前能落地的有三种角色：参数寻优、异常检测、预测性补偿。

参数寻优是最成熟的。比如注塑机的温度曲线、包装机的张力设定，传统靠老师傅调，现在可以用强化学习或者贝叶斯优化自动找最优参数。AI 不直接控制，它给 PLC 下发设定值，PLC 还是按原来的逻辑跑。

异常检测是第二成熟的。用振动、电流、温度这些信号，训练一个自编码器或者孤立森林，实时判断设备状态。异常了给 PLC 一个信号，PLC 决定是降速还是停机。

预测性补偿是最前沿的。比如机械臂的轨迹跟踪，传统 PID 在高速下会有滞后，用神经网络预测滞后量，提前补偿。这个对实时性要求最高，模型推理要在几百微秒内完成。

4.2 模型怎么部署到控制层：三种架构

AI 模型跑在哪，决定了整个架构。我列三种我实际用过的。

第一种：模型跑在软 PLC 同一台机器的非实时核上。这是最简单的。Python 进程绑到非实时核，通过共享内存跟 ST 逻辑通信。优点是延迟低（同一台机器，共享内存通信在微秒级），缺点是模型不能太大，不然抢 CPU 影响实时任务。适合轻量模型，比如几层的 MLP 或者小型的 LSTM。

第二种：模型跑在边缘服务器上，通过 TSN 网络跟 PLC 通信。边缘服务器可以配 GPU，跑大一点的模型。通信走 TSN 的确定性通道，延迟可控。缺点是多了网络这一跳，端到端延迟比第一种高，但通常也在毫秒级以内。适合视觉检测、复杂预测这类场景。

第三种：模型跑在云端，PLC 只做推理结果的执行。这个延迟最大，通常只用于非实时的参数优化，比如每天跑一次寻优，把新参数下发给 PLC。实时控制回路不依赖云端。

我自己的项目里，第一种和第二种用得最多。第一种适合快速验证，第二种适合正式部署。第三种只在参数寻优场景用。

4.3 实操：把一个小模型塞进控制回路

我拿一个真实案例讲。客户有一条薄膜生产线，张力控制老是不稳，传统 PID 在换卷的时候会波动。我们做了一个 LSTM 模型，输入是最近 200 毫秒的张力、速度、卷径，输出是 PID 参数的修正量。

模型很小，两层 LSTM，隐藏层 32，参数量不到一万。训练用历史数据，离线做。部署的时候，模型转成 ONNX，用 onnxruntime 跑在工控机的非实时核上。

通信用的是共享内存。ST 逻辑每个扫描周期把输入写到一个共享内存区，Python 进程读出来，推理，把输出写回另一个区。ST 逻辑下一个周期读输出，应用到 PID 上。

这里有几个关键点。第一是同步，共享内存要加锁或者用无锁环形缓冲，不然会读到半截数据。我用的是双缓冲加原子标志位，简单可靠。第二是超时，Python 进程如果卡住，ST 逻辑不能等，要用上一次的输出或者回退到默认 PID。第三是模型更新，新模型上线不能停线，我的做法是双模型热切换，新模型先在影子模式跑，对比输出，确认没问题再切。

实测下来，换卷时的张力波动从正负 8% 降到正负 3%，效果明显。推理延迟平均 80 微秒，最大 200 微秒，对 1 毫秒的扫描周期来说完全够用。

4.4 AI 进控制层的风险与边界

AI 进控制层，最大的风险是不可解释。传统 PID 你还能分析，神经网络出问题你都不知道为什么。所以我的原则是：AI 只做建议，不做决策。最终的控制指令还是由确定性逻辑发出，AI 的输出要经过限幅、速率限制、合理性检查才能生效。

第二个风险是数据漂移。模型训练用的数据跟实际运行的数据分布不一致，效果会掉。我一般会加一个在线监控，统计输入输出的分布，偏移超过阈值就报警，提示重新训练。

第三个风险是实时性不达标。模型推理时间波动大，偶尔超过扫描周期，会导致控制抖动。解决办法是给推理设硬超时，超时就回退，同时监控超时率，高了就优化模型或者换硬件。

提示：AI 模型进控制层之前，一定要在影子模式跑至少两周，对比它跟原逻辑的输出差异。我见过直接上线的项目，模型在某个工况下输出异常值，导致整批产品报废。

5. 三件事怎么凑到一起：一个融合架构的落地记录

5.1 整体架构设计

我把上面三块技术整合到一个项目里，客户是一条精密装配线，要求节拍 0.8 秒，良率 99.5% 以上。原来的架构是传统 PLC + 现场总线 + 独立视觉系统，数据不通，换型要人工调半天。

新架构是这样的：软 PLC 跑在工控机上，EtherCAT 接伺服和 IO，TSN 网络接视觉相机和边缘服务器，AI 模型跑在边缘服务器上做视觉检测和参数寻优。IT 侧通过 OPC UA 跟 MES 通信，数据进时序数据库。

这个架构的核心思路是分层确定性。最底层是 EtherCAT，保证运动控制的微秒级确定性；中间层是 TSN，保证视觉和 AI 推理的毫秒级确定性；最上层是普通以太网，跑 MES 和数据采集，尽力而为就行。

5.2 关键环节的实现细节

时间同步是第一个要解决的。EtherCAT 有自己的分布式时钟，TSN 用 gPTP，两者要对齐。我的做法是让工控机同时做 EtherCAT 主站和 gPTP grandmaster，用一个时钟源驱动两者。这样视觉相机的时间戳跟伺服的位置能对上，做视觉引导的时候不用做时间对齐。

数据流是第二个要设计的。视觉相机的图像走 TSN 到边缘服务器，推理结果走 TSN 回工控机。工控机上的软 PLC 把结果跟运动指令融合，下发给伺服。整个过程要在 0.8 秒节拍内完成，留给视觉和推理的时间大概 300 毫秒。

AI 模型是第三个要调的。视觉检测用的是 YOLO 的小型版本，输入 640x640，推理在边缘服务器的 GPU 上跑，单帧 15 毫秒。参数寻优用的是贝叶斯优化，每生产 100 件跑一次，调整装配压力曲线。

5.3 实测数据与效果

项目跑了三个月，我记录了一些数据。控制回路的抖动，软 PLC 侧最大 45 微秒，满足 50 微秒的要求。TSN 网络的端到端延迟，视觉图像从相机到边缘服务器平均 1.2 毫秒，最大 2.5 毫秒。AI 推理延迟平均 18 毫秒，最大 35 毫秒。

良率从原来的 98.2% 提到 99.6%，换型时间从 30 分钟降到 5 分钟。这些提升主要来自 AI 参数寻优和视觉检测的实时反馈，不是单一技术的功劳。

5.4 这个架构的适用边界

不是所有产线都适合这么搞。节拍太快的（比如 0.1 秒以内），TSN 和 AI 的延迟占比太高，不划算。产品太单一的，参数寻优没意义，传统 PLC 够用。预算太紧的，TSN 交换机和边缘服务器都不便宜，回本周期要算清楚。

我的判断标准是：如果换型频繁、质量要求高、数据要打通，那值得上；如果是大批量单一品种，传统方案更经济。

6. 常见问题与排查技巧实录

6.1 软 PLC 抖动超标怎么查

抖动超标是最常见的问题。我的排查顺序是：先看 CPU 隔离有没有生效（cat /proc/cmdline确认 isolcpus），再看中断有没有绑对（cat /proc/interrupts看实时核上的中断数），然后看有没有其他进程在抢（top -H看实时核上的线程），最后看 BIOS 设置（C-State、P-State 有没有关）。

如果这些都排除了还超标，用ftrace抓一下实时任务的调度延迟，看是哪个环节引入的。我遇到过一次是网卡驱动的问题，换了个驱动版本就好了。

6.2 TSN 时间同步不上的排查

同步不上，先看物理层。网线、光模块、交换机端口，这些基础的东西最容易出问题。然后看配置，域号、优先级、同步周期，两边要一致。再看交换机的时间戳能力，有些交换机只支持软件时间戳，精度上不去。

我遇到过一次是交换机的固件 bug，gPTP 报文处理有问题，升级固件解决。还有一次是网络里有非 TSN 设备在发 gPTP 报文，干扰了主时钟选举，把那个设备隔离就好了。

6.3 AI 模型推理超时怎么处理

推理超时，先看模型大小。如果模型太大，换小模型或者做量化。再看硬件，CPU 推理慢就换 GPU 或者 NPU。再看进程优先级，推理进程要绑到非实时核，但优先级要够高，别被其他进程挤。

如果这些都做了还超时，那就是模型本身的问题，输入数据分布变了，推理路径变长。这时候要加监控，统计推理时间的分布，超阈值就报警。

6.4 常见问题速查表

6.5 几个独家避坑技巧

第一个：软 PLC 的工控机，BIOS 里一定要关掉 "Energy Efficient Turbo" 或者类似的节能选项。我见过一个项目，CPU 在低负载时降频，负载上来时升频有延迟，导致抖动周期性超标。关掉之后立刻好。

第二个：TSN 交换机的门控列表，周期要跟控制周期成整数倍关系。比如控制周期 1 毫秒，门控周期就设 1 毫秒或者 2 毫秒，别设 1.5 毫秒，不然会有累积误差。

第三个：AI 模型的输入要做归一化和异常值过滤。我见过模型因为一个传感器瞬时跳变输出离谱值，导致整批产品参数跑偏。加一个简单的限幅和滑动平均就能避免。

第四个：所有配置都要进版本管理。软 PLC 的运行时配置、TSN 的门控列表、AI 模型的版本，全部用 Git 管起来。出问题能回滚，换型能复用，这是 IT 那套东西带给 OT 的最大价值。

第五个：上线前一定要做压力测试。模拟最坏工况，比如所有轴同时加速、视觉满负荷、AI 推理排队，看抖动和延迟还满不满足。我一般会跑 72 小时，覆盖各种工况组合。

7. 这套东西后续还能怎么扩展

我现在在试的一个方向是多 AI 协作。不是一个大模型包打天下，而是几个小模型各管一块——一个管视觉、一个管参数、一个管异常检测，它们之间通过消息总线通信，互相校验。这样单个模型出问题不会影响全局，也更容易迭代。

另一个方向是控制逻辑的自动化生成。用 AI 读工艺文档和 historan 数据，自动生成 ST 代码框架，工程师只做审核和微调。这个还在早期，但已经有苗头了。

还有一个是数字孪生跟控制层的闭环。孪生模型实时跟产线同步，在虚拟环境里试新参数，验证通过再下发到实际 PLC。这个对换型频繁的产线价值很大，能大幅减少试错成本。

我个人在实际操作中的体会是，IT/OT 融合最难的不是技术，是两边人的思维差异。IT 的人要理解现场的物理约束，OT 的人要接受软件工程的迭代方式。技术方案再漂亮，两边不配合也落不了地。所以我现在做项目，第一步不是选型，是把两边的人拉到一起，先对齐目标，再谈技术。这个顺序错了，后面全是坑。