1. 2026 AI工业控制系统搭建的核心思路拆解

1.1 为什么2026年的工业控制系统必须和AI深度绑定

先说一个我自己的观察。2023年之前，大部分工厂里的“工业控制系统”本质上还是PLC加SCADA那一套，逻辑是固定的：传感器读数超过阈值就报警，电机温度高了就降频。这套东西稳定、可靠，但有一个致命问题——它只会执行人预先写好的规则，不会自己判断“这个阈值在当前工况下是不是还合理”。

到了2026年，情况完全变了。产线上的传感器密度比五年前高了至少三倍，一个中型注塑车间一天产生的时序数据点轻松过亿。靠人工去调PID参数、去写报警规则，根本跟不上生产节拍的变化。这时候AI的价值就出来了：它可以从历史数据里学出“什么工况下该用什么参数”，并且随着原料批次、环境温湿度、设备磨损程度的变化自动调整。

所以“AI工业控制系统”不是把AI硬塞进PLC里，而是构建一套分层架构：底层仍然是高实时性的控制执行层，中间层做数据汇聚和特征工程，上层用AI模型做决策优化，再把优化结果下发到底层。这个分层思路是整篇文章的骨架，后面所有细节都围绕它展开。

1.2 搭建前必须想清楚的三个选型问题

很多人在动手之前容易犯一个错误：先选工具再想场景。我见过一个团队花了两个月搭了一套Kubernetes集群，结果发现他们的产线数据采集频率只有1Hz，根本用不上容器编排。所以搭建之前，先把这三个问题回答清楚。

第一个问题：你的控制闭环周期是多少？如果闭环周期在10毫秒以下，比如伺服电机的电流环控制，那AI模型只能放在上位机做参数整定，不能直接进闭环。如果闭环周期在100毫秒到1秒之间，比如温度控制、张力控制，那AI模型可以直接参与决策。如果闭环周期在秒级以上，比如排产优化、能耗调度，那AI可以放开手脚做。

第二个问题：你的数据是集中式还是分布式？一条产线可能只有几十个传感器，但一个工厂可能有几十条产线。如果数据量在每天千万级以下，单台服务器加时序数据库就够了。如果每天上亿级，就需要考虑分布式采集和存储，比如用MQTT做边缘汇聚，再用Kafka做中心缓冲。

第三个问题：你的团队AI工程能力如何？如果团队里没有人懂PyTorch或者TensorFlow，那建议先从现成的AI平台入手，比如用Coze或者类似的工作流工具搭建简单的推理流程。如果团队有算法工程师，那可以自己训练模型，用ONNX Runtime做推理部署。

这三个问题决定了你后面所有技术选型的方向。我个人的经验是，大部分中小型工业场景，闭环周期在200毫秒到2秒之间，数据量在每天百万到千万级，团队有基本的Python能力但缺乏深度学习经验。针对这种情况，我下面给出的方案会偏向“轻量级AI+成熟工业协议”的组合。

1.3 整体架构：四层模型与数据流向

我把AI工业控制系统分成四层，从下往上依次是设备层、边缘层、平台层和应用层。

设备层包括PLC、传感器、执行器、变频器这些现场设备。这一层的关键是协议兼容性。2026年主流的工业协议还是Modbus、OPC UA、Profinet、EtherCAT这几种。Modbus最简单但速度慢，OPC UA语义丰富但配置复杂，Profinet和EtherCAT实时性好但需要专用硬件。我的建议是：如果设备支持OPC UA，优先用OPC UA，因为它的信息模型可以直接把设备语义传给上层，省去大量手工映射工作。

边缘层是AI工业控制系统的核心创新点。这一层通常是一台工业PC或者高性能网关，运行着数据采集程序、轻量级推理引擎和实时控制逻辑。边缘层的作用是“就近处理”：把高频采集的数据在本地做滤波、降采样、特征提取，只把有用的特征和推理结果上传到平台层。这样做的好处是减少网络带宽压力，同时保证控制闭环的实时性。

平台层负责数据存储、模型训练、模型管理和可视化。这一层可以用单机部署，也可以用集群部署。对于大多数工厂，我建议先用单机加Docker的方式跑起来，等数据量真的上来了再考虑分布式。时序数据库选TimescaleDB或者InfluxDB，模型训练用PyTorch，模型管理用MLflow，可视化用Grafana。这套组合在社区里资料最多，遇到问题容易找到答案。

应用层是面向操作员和管理者的界面。可以是Web端的大屏，也可以是移动端的App。这一层的关键是“可解释性”：AI给出了一个控制建议，操作员要知道为什么。所以应用层不能只显示一个数字，还要显示模型置信度、关键特征贡献度、历史相似工况的对比。

数据流向是：设备层通过OPC UA或Modbus把数据推到边缘层，边缘层做预处理后一路留在本地做实时推理，一路通过MQTT推到平台层做存储和训练。平台层训练好的模型通过OTA方式下发到边缘层。应用层从平台层读取数据和模型解释结果。

2. 核心细节解析与实操要点

2.1 边缘层硬件选型：不是越贵越好

边缘层的硬件选型直接决定了整个系统的成本和性能。我见过两种极端：一种是花两万块买工控机，结果CPU性能过剩，GPU根本用不上；另一种是拿树莓派硬扛，结果数据量一上来就丢包。

我的经验是，边缘层硬件按以下标准选：

这里有一个容易被忽略的点：工业现场的电磁干扰。我试过用消费级迷你主机做边缘节点，结果变频器一启动，网卡就掉线。后来换成带金属外壳和隔离电源的工控机，问题才解决。所以边缘层硬件一定要选工业级，工作温度范围至少-20到60度，电源输入要支持宽压。

另外，边缘层的操作系统建议用Ubuntu Server LTS或者Debian，不要用Windows。原因很简单：Linux的实时内核补丁（PREEMPT_RT）可以把调度延迟压到100微秒以内，而且Docker和Python生态在Linux上更成熟。如果团队只会Windows，那至少用Windows 10 IoT Enterprise，不要用普通版。

2.2 数据采集：OPC UA与Modbus的取舍

数据采集是AI工业控制系统的入口，采集不稳定，后面全是空中楼阁。2026年主流的采集方式有两种：OPC UA和Modbus。

OPC UA的优势是自带信息模型。比如一个温度传感器，在OPC UA里可以定义成“设备-通道-温度”的层级结构，还带单位、量程、精度等元数据。上层应用直接读这个结构就行，不需要再维护一张映射表。缺点是配置复杂，需要证书管理，而且老设备不一定支持。

Modbus的优势是简单、通用。几乎所有的PLC和仪表都支持Modbus RTU或者Modbus TCP。缺点是它只传数值，不传语义。你读到一个寄存器值是250，它可能是温度、压力、流量，全靠你自己在代码里映射。

我的建议是：新项目优先用OPC UA，老设备改造用Modbus加一层语义映射。具体做法是，在边缘层写一个采集程序，用Python的opcua库或者pymodbus库，把采集到的数据统一转成JSON格式，带上设备ID、测点ID、时间戳、数值、单位。这样上层就不用关心底层协议了。

采集频率的设置也有讲究。不是越高越好。对于温度、压力这种慢变量，1Hz足够了。对于振动、电流这种快变量，可能需要1kHz。但1kHz的数据如果全部上传，网络和存储都扛不住。所以边缘层要做降采样和特征提取：原始数据在本地算均方根、峰值、峭度，只把特征值上传。

注意：采集程序一定要做断线重连和本地缓存。我踩过的坑是，网络交换机重启了30秒，采集程序直接崩溃，丢了半小时数据。后来加了SQLite本地缓存，网络恢复后自动补传，才解决这个问题。

2.3 AI模型选型：从LSTM到轻量级Transformer

工业控制场景的AI模型和互联网场景有很大不同。互联网场景可以接受几百毫秒的推理延迟，工业场景不行。互联网场景的数据分布相对稳定，工业场景的数据分布会随着设备磨损、原料批次、环境变化而漂移。

2026年工业控制场景主流的模型有三类：

第一类是LSTM和GRU。适合处理时序数据，参数量小，推理速度快。一个两层LSTM，隐藏层64维，在边缘CPU上推理一次只要几毫秒。缺点是长期依赖建模能力弱，超过100个时间步就记不住了。

第二类是轻量级Transformer。比如TinyBERT或者DistilBERT的时序版本。注意力机制可以捕捉长距离依赖，但参数量比LSTM大。在边缘GPU上推理一次大概10-20毫秒。适合闭环周期在100毫秒以上的场景。

第三类是传统机器学习模型。比如XGBoost、LightGBM、随机森林。这些模型在表格数据上表现很好，训练速度快，可解释性强。我经常用XGBoost做基线模型，如果它的效果和深度学习模型差不多，那就直接用XGBoost，省事。

我的实操建议是：先用XGBoost或者LightGBM跑一个基线，看看特征重要性。如果基线效果已经满足要求，就不要上深度学习。如果基线不够，再试LSTM。如果LSTM还不够，再试轻量级Transformer。不要一上来就搞大模型，工业场景的数据量通常撑不起大模型。

模型训练的数据集划分也要注意。不能用随机划分，要用时间序列划分。比如用前80%的时间段做训练，后20%做测试。否则会出现数据泄露，测试集效果虚高。

2.4 实时推理与控制的衔接

AI模型输出的是一个预测值或者分类结果，但控制执行器需要的是具体的控制量。这中间需要一个“决策映射”环节。

举个例子：AI模型预测未来10秒温度会上升5度，输出是一个数值。但控制执行器需要知道“加热功率应该降低多少”。这个映射关系可以用PID控制器来实现：把AI的预测值作为PID的设定值，PID根据当前温度和设定值的偏差计算加热功率。

这样做的好处是，AI只负责“预测未来”，PID负责“消除偏差”。两者解耦，AI模型更新时不需要重新整定PID参数。

另一种方式是直接让AI输出控制量。比如用强化学习训练一个策略网络，输入是当前状态，输出是加热功率。这种方式更端到端，但训练难度大，而且安全性难以保证。我建议在非关键回路可以尝试，关键回路还是用AI+PID的方式。

实时推理的部署方式也有两种：一种是边缘层直接加载ONNX模型，用ONNX Runtime推理；另一种是边缘层把特征发给平台层，平台层推理后再把结果发回来。前者延迟低但模型更新麻烦，后者延迟高但模型管理方便。我的做法是：关键回路用前者，非关键回路用后者。

提示：ONNX Runtime在ARM CPU上的性能优化很重要。我试过用默认配置，推理一次要50毫秒。后来开了int8量化，降到15毫秒。再开了线程亲和性设置，降到8毫秒。这些优化在官方文档里都有，但容易被忽略。

3. 实操过程与核心环节实现

3.1 环境搭建：从裸机到可运行系统

假设你拿到了一台工控机，装好了Ubuntu Server 22.04 LTS。下面是我实际操作的步骤。

第一步：安装Docker和Docker Compose。不要用apt自带的版本，太老。用官方脚本安装最新稳定版。

curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh sudo usermod -aG docker $USER

安装完成后退出重新登录，让用户组生效。然后安装Docker Compose插件：

sudo apt-get install docker-compose-plugin

第二步：配置实时内核。Ubuntu默认内核不是实时内核，调度延迟在毫秒级。对于闭环周期100毫秒以上的场景，这个延迟可以接受。但如果闭环周期在10毫秒级，就需要装PREEMPT_RT补丁。安装方法：

sudo apt-get install linux-image-rt-generic

然后修改GRUB配置，默认启动实时内核。重启后用uname -a确认内核版本带“rt”字样。

第三步：部署时序数据库。我用TimescaleDB，因为它是PostgreSQL的扩展，SQL语法通用，学习成本低。

version: '3' services: timescaledb: image: timescale/timescaledb:latest-pg14 ports: - "5432:5432" environment: POSTGRES_PASSWORD: yourpassword volumes: - ./data:/var/lib/postgresql/data

启动后进入容器创建 hypertable：

CREATE TABLE sensor_data ( time TIMESTAMPTZ NOT NULL, device_id TEXT, point_id TEXT, value DOUBLE PRECISION ); SELECT create_hypertable('sensor_data', 'time');

第四步：部署MQTT Broker。用Eclipse Mosquitto，轻量且稳定。

mosquitto: image: eclipse-mosquitto:latest ports: - "1883:1883" volumes: - ./mosquitto.conf:/mosquitto/config/mosquitto.conf

mosquitto.conf里至少要配置允许匿名连接和持久化：

allow_anonymous true persistence true persistence_location /mosquitto/data/

第五步：部署采集程序。用Python写一个采集脚本，通过OPC UA读取数据，转成JSON后发布到MQTT。

from opcua import Client import paho.mqtt.client as mqtt import json import time opc_client = Client("opc.tcp://192.168.1.10:4840") opc_client.connect() mqtt_client = mqtt.Client() mqtt_client.connect("localhost", 1883) nodes = { "temperature": opc_client.get_node("ns=2;s=Device1.Temperature"), "pressure": opc_client.get_node("ns=2;s=Device1.Pressure") } while True: data = {} for name, node in nodes.items(): data[name] = node.get_value() data["timestamp"] = time.time() mqtt_client.publish("factory/line1/sensor", json.dumps(data)) time.sleep(1)

这个脚本是最简版本，实际部署时要加异常处理和本地缓存。

3.2 模型训练：从数据到ONNX

假设你已经采集了一周的数据，存在TimescaleDB里。下面是从数据到模型的完整流程。

第一步：数据导出和清洗。用SQL把数据导成CSV：

COPY ( SELECT time, device_id, point_id, value FROM sensor_data WHERE time > NOW() - INTERVAL '7 days' ORDER BY time ) TO '/tmp/sensor_data.csv' WITH CSV HEADER;

然后处理缺失值和异常值。工业数据常见的异常是传感器断线导致的零值或者满量程值。我的做法是：如果连续5个点都是同一个值，标记为可疑；如果值超过量程的1.5倍，标记为异常。标记后的数据用线性插值补全。

第二步：特征工程。对于时序数据，我通常构造以下特征：

• 滑动窗口均值（窗口大小10、30、60）
• 滑动窗口标准差
• 一阶差分
• 滑动窗口最大最小值
• 傅里叶变换的前5个频率分量

这些特征用pandas的rolling函数就能算：

df['mean_10'] = df['value'].rolling(10).mean() df['std_30'] = df['value'].rolling(30).std() df['diff_1'] = df['value'].diff()

第三步：模型训练。用PyTorch定义一个LSTM：

import torch import torch.nn as nn class LSTMModel(nn.Module): def __init__(self, input_size, hidden_size, output_size): super().__init__() self.lstm = nn.LSTM(input_size, hidden_size, batch_first=True) self.fc = nn.Linear(hidden_size, output_size) def forward(self, x): out, _ = self.lstm(x) out = self.fc(out[:, -1, :]) return out

训练时用Adam优化器，学习率1e-3，batch size 64，训练100个epoch。损失函数用MSE。注意要用时间序列划分验证集，不能用随机划分。

第四步：模型导出为ONNX。PyTorch训练好的模型要转成ONNX才能在边缘层用ONNX Runtime推理：

dummy_input = torch.randn(1, 60, input_size) torch.onnx.export(model, dummy_input, "model.onnx", input_names=["input"], output_names=["output"], dynamic_axes={"input": {0: "batch"}, "output": {0: "batch"}})

导出后可以用onnxruntime验证一下：

import onnxruntime as ort sess = ort.InferenceSession("model.onnx") result = sess.run(None, {"input": dummy_input.numpy()})

3.3 边缘推理服务部署

模型训练好之后，要在边缘层部署一个推理服务。我用FastAPI写一个简单的HTTP服务：

from fastapi import FastAPI import onnxruntime as ort import numpy as np app = FastAPI() sess = ort.InferenceSession("model.onnx") @app.post("/predict") def predict(data: dict): features = np.array(data["features"], dtype=np.float32) features = features.reshape(1, 60, -1) result = sess.run(None, {"input": features}) return {"prediction": result[0].tolist()}

然后用uvicorn启动：

uvicorn main:app --host 0.0.0.0 --port 8000

这个服务可以放在Docker里，和采集程序、MQTT Broker在同一个docker-compose网络里。采集程序每收到一批数据，就调用一次推理服务，把结果通过MQTT发布到控制主题。

控制程序订阅控制主题，收到AI的预测值后，用PID计算实际控制量，再通过OPC UA写回PLC。

3.4 可视化与监控

Grafana是工业场景最常用的可视化工具。配置TimescaleDB数据源后，可以画实时曲线、历史趋势、报警统计。

我通常会做三个面板：

第一个是实时监控面板。显示当前所有关键测点的数值和AI预测值。用Grafana的Stat面板和Time series面板。

第二个是模型性能面板。显示AI预测值和实际值的偏差，以及偏差的滑动平均。如果偏差持续增大，说明模型需要重新训练。

第三个是系统健康面板。显示边缘层CPU、内存、磁盘使用率，MQTT消息队列长度，推理服务延迟。这些指标用Prometheus采集，Grafana展示。

提示：Grafana的报警功能很实用。可以设置“AI预测偏差连续10分钟超过阈值”就发邮件或者发Webhook到企业微信。这样不用一直盯着屏幕。

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

4.1 数据采集丢包怎么办

这是最常见的问题。表现是MQTT消息时断时续，或者数据库里出现大段空白。

排查思路分三步：

第一步：确认是网络问题还是程序问题。在边缘层用tcpdump抓包，看OPC UA的请求和响应是否完整。如果请求发出去了但没收到响应，那是网络问题。如果根本没发出请求，那是程序问题。

第二步：如果是网络问题，检查交换机和网线。工业现场电磁干扰大，普通网线没有屏蔽层，容易丢包。换成带屏蔽层的工业网线，或者用光纤。另外检查交换机是否开启了风暴抑制，有时候广播风暴会导致端口阻塞。

第三步：如果是程序问题，检查异常处理。我见过一个采集程序，OPC UA连接断开后没有重连，直接退出了。后来加了try-except和重连循环，问题解决。

while True: try: opc_client.connect() break except Exception as e: print(f"连接失败: {e}, 5秒后重试") time.sleep(5)

4.2 模型推理延迟过高怎么办

如果推理延迟超过闭环周期，整个系统就不稳定了。优化方向有四个：

第一，模型量化。把FP32模型转成INT8，推理速度可以提升2-4倍，精度损失通常在1%以内。ONNX Runtime支持动态量化：

from onnxruntime.quantization import quantize_dynamic quantize_dynamic("model.onnx", "model_quantized.onnx")

第二，减少输入窗口长度。如果原来用60个时间步，可以试试30个。窗口越短，推理越快。但要注意，窗口太短可能丢失重要信息。

第三，用ONNX Runtime的优化选项。设置graph_optimization_level为ORT_ENABLE_ALL，开启所有图优化。

第四，换硬件。如果CPU实在扛不住，加一块入门级GPU，比如NVIDIA T4或者RTX A2000。推理速度可以提升10倍以上。

4.3 模型效果随时间下降怎么办

这是工业AI的典型问题，叫“概念漂移”。设备磨损、原料变化、环境变化都会导致数据分布改变，模型在新数据上效果变差。

解决方法有三种：

第一种是定期重新训练。比如每周用最近一个月的数据重新训练一次模型。这种方法简单，但需要标注数据。如果标注成本高，可以用无监督的漂移检测，只在检测到漂移时才重新训练。

第二种是在线学习。模型在推理的同时，用新数据微调。这种方法响应快，但容易过拟合，而且需要设计安全的更新策略。

第三种是集成多个模型。训练多个不同时间段的模型，推理时用加权平均。这种方法鲁棒性好，但推理成本高。

我的做法是：先用第一种，每周重新训练。同时监控预测偏差，如果偏差超过阈值，就触发紧急重新训练。

4.4 常见问题速查表

4.5 几个我踩过的坑

第一个坑：时间同步。边缘层和平台层的时间如果不一致，数据对不上。我试过用NTP同步，但工业现场的网络经常不通外网。后来在边缘层装了一个本地NTP服务器，所有设备都从它同步时间。

第二个坑：Docker容器时区。默认容器时区是UTC，和本地时间差8小时。Grafana显示的时间全是错的。后来在docker-compose里加了TZ=Asia/Shanghai环境变量才解决。

第三个坑：模型输入归一化。训练时做了归一化，推理时忘了做，结果预测值完全不对。后来把归一化参数保存成JSON文件，推理时加载，才保证一致。

第四个坑：OPC UA节点ID硬编码。设备一换，节点ID就变了，采集程序要改代码。后来改成从配置文件读取节点ID，换设备只需要改配置文件。

第五个坑：Grafana报警太敏感。设了“偏差超过5%就报警”，结果一天收几百封邮件。后来改成“偏差超过5%且持续10分钟才报警”，邮件少了很多，而且都是真正需要关注的。

5. 从单机到集群的扩展路径

5.1 什么时候需要扩展

单台边缘服务器能支撑的规模是有限的。根据我的经验，一台六核x86、16GB内存的工控机，可以同时处理200个数据点的采集、10个模型的推理、以及对应的控制逻辑。如果超过这个规模，就会出现CPU满载、推理延迟增加、数据丢失等问题。

扩展的触发条件有三个：数据点超过200个、模型数量超过10个、或者闭环周期要求低于50毫秒。满足任何一个，就需要考虑扩展。

5.2 水平扩展：多边缘节点加中心平台

最简单的扩展方式是增加边缘节点。每个边缘节点负责一条产线或者一个车间，独立完成采集、推理和控制。中心平台只负责数据存储、模型训练和全局监控。

这种架构的好处是边缘节点之间互不影响，一个节点故障不会导致全线停产。缺点是模型更新麻烦，需要逐个节点下发。解决方法是用容器镜像仓库，把模型和推理服务打包成Docker镜像，边缘节点定期拉取最新镜像。

5.3 垂直扩展：边缘集群加负载均衡

如果单条产线的数据量就很大，比如高频振动监测，那就需要在一个产线内部做集群。用Kubernetes或者K3s部署多个推理Pod，前面加一个负载均衡器。采集程序把数据发给负载均衡器，由它分发到不同的推理Pod。

这种架构的复杂度高，需要团队有容器编排经验。我的建议是，除非数据量真的很大，否则优先用水平扩展，不要过早引入Kubernetes。

5.4 模型管理：从手工到MLflow

单机时代，模型文件直接放在边缘层目录里。多节点时代，就需要一个模型管理系统。MLflow是开源方案里最成熟的。

用MLflow跟踪实验、注册模型、管理版本。边缘节点通过MLflow的REST API拉取最新模型。每次模型更新，MLflow自动记录版本号和性能指标，方便回滚。

import mlflow mlflow.set_tracking_uri("http://platform:5000") mlflow.pytorch.log_model(model, "model")

然后在边缘层用MLflow客户端下载：

model_uri = "models:/anomaly_detection/latest" model = mlflow.pytorch.load_model(model_uri)

这套流程跑通之后，模型迭代速度会快很多。以前更新一次模型要半小时，现在只要五分钟。

6. 安全与可靠性设计

6.1 网络安全：工业现场的特殊性

工业现场的网络和办公网络必须隔离。我见过一个工厂，办公网的勒索病毒通过共享交换机传到了工控网，导致PLC被加密，停产三天。所以AI工业控制系统的网络设计要遵循“三层隔离”原则：

第一层是设备层隔离。PLC和传感器在独立的VLAN里，只允许边缘层的采集程序访问。禁止设备层直接访问外网。

第二层是边缘层隔离。边缘层可以访问设备层和平台层，但平台层不能主动访问边缘层。所有通信由边缘层发起。

第三层是平台层隔离。平台层在独立的DMZ区，只能通过跳板机访问。平台层的数据库和模型仓库要加密存储。

6.2 控制安全：AI不能直接写PLC

这是一个原则性问题：AI的输出不能直接写PLC。必须经过一个“安全网关”做校验。

安全网关的逻辑是：AI输出一个控制量，安全网关检查这个控制量是否在允许范围内。如果超出范围，就拒绝执行，并报警。如果连续多次被拒绝，就自动切换到手动控制模式。

这个安全网关可以用一个简单的Python脚本实现：

def safety_check(ai_output, min_val, max_val): if ai_output < min_val or ai_output > max_val: return None, "超出安全范围" return ai_output, "OK"

6.3 数据安全：备份与恢复

工业数据是核心资产，必须定期备份。我的做法是：TimescaleDB每天做一次全量备份，每小时做一次增量备份。备份文件存到NAS和对象存储两处。

恢复演练也很重要。我每个季度做一次恢复演练，从备份文件恢复数据库，验证数据完整性。这个习惯救过我一次：有一次硬盘故障，因为备份可用，只丢了1小时数据。

7. 成本估算与团队配置

7.1 硬件成本

以一个中型工厂、两条产线、200个数据点为例：

这个成本不含PLC和传感器，假设这些是已有设备。

7.2 软件成本

全部用开源软件，软件许可成本为零。但需要考虑人力成本。

7.3 团队配置

一个能跑起来的AI工业控制系统，至少需要三种角色：

自动化工程师：懂PLC、OPC UA、PID控制。负责设备层对接和控制逻辑。

数据工程师：懂Python、SQL、MQTT。负责数据采集、清洗、存储。

算法工程师：懂PyTorch、ONNX、特征工程。负责模型训练和部署。

如果团队小，一个人可以兼多个角色。但完全不懂自动化的人做不了这个，因为工业协议和实时控制的坑太多。

8. 实际案例：注塑机温度控制

8.1 场景描述

我参与过一个注塑车间的AI温度控制项目。注塑机的料筒温度控制直接影响产品质量。传统PID控制的问题是：换料时温度波动大，需要人工重新整定PID参数。而且不同批次的原料熔点有差异，固定参数很难适应。

8.2 方案设计

在原有PID控制的基础上，加一层AI预测。AI模型输入是最近5分钟的料筒温度、加热功率、环境温度、原料批次号，输出是未来30秒的温度预测值。PID的设定值由AI动态调整：如果AI预测温度会超调，PID设定值就提前降低。

8.3 实施效果

上线运行三个月后，温度控制精度从±5度提升到±2度，换料时的稳定时间从15分钟缩短到5分钟。产品不良率下降了1.2个百分点。

8.4 遇到的特殊问题

注塑车间的环境温度很高，夏天车间温度能到40度。边缘工控机放在电控柜里，柜内温度超过50度，工控机频繁死机。后来在电控柜里加了工业空调，问题才解决。这个教训是：工业现场的边缘设备，散热设计比性能更重要。

9. 后续扩展方向

9.1 多模态融合

现在的系统主要处理时序数据。后续可以加入视觉数据，比如用摄像头监控产品表面缺陷，把视觉特征和时序特征融合，做更全面的质量预测。

9.2 强化学习优化

现在的AI是监督学习，需要标注数据。后续可以尝试强化学习，让AI在仿真环境里自己探索最优控制策略。但强化学习的安全性需要特别设计，不能直接上产线。

9.3 边缘联邦学习

如果工厂有多个车间，每个车间的数据不出本地，但可以共享模型梯度。用联邦学习的方式，让多个车间的模型共同进化，同时保护数据隐私。

9.4 与大模型结合

2026年大模型在工业场景的应用还处于早期。但可以尝试用大模型做故障诊断的问答系统：操作员用自然语言描述故障现象，大模型结合历史维修记录给出排查建议。这个方向不需要实时控制，风险低，适合作为切入点。

我个人在实际操作中的体会是，AI工业控制系统的搭建，技术只占三成，七成是对工业场景的理解。不了解注塑工艺的人，调不出好的温度控制模型；不了解PLC扫描周期的人，设计不出稳定的控制架构。所以如果你要入这个方向，先去车间待一个月，把工艺流程摸清楚，再动手写代码。这个顺序不能反。