1. 从零理解AI工业控制系统的真实边界1.1 这套系统到底在解决什么问题工业控制系统这个词听起来很重但拆开看其实就三件事采集现场数据、按规则做决策、把决策下发到执行机构。传统的PLC和SCADA已经把这三件事做了几十年稳定可靠那为什么还要加AI因为传统控制逻辑是if-else写死的遇到工况漂移、原料批次差异、设备老化这些慢变量要么频繁人工调参要么控制品质一路下滑。AI工业控制系统的核心价值就是让控制策略具备在线自适应能力——用数据驱动的方式去补偿那些写不进梯形图的隐性因素。我接触过的落地场景里最典型的是三类一是过程工业的软测量比如用温度、压力、流量去推断无法直接在线测量的成分浓度二是设备预测性维护从振动和电流信号里提前识别轴承劣化趋势三是复杂回路的先进控制用模型预测控制替代PID处理大滞后、强耦合的回路。这三类的共同点是传统方法能做但做不好AI能补上那块短板。适合读这篇内容的人我大致分两类。一类是自动化工程师手上有PLC和上位机想往上叠一层智能决策另一类是算法工程师模型训得不错但不知道怎么跟现场设备对接。这两类人中间有一条很深的沟我写这篇的目的就是把这条沟填上。1.2 2026年这个时间点的技术前提为什么现在谈这个比三年前靠谱三个条件成熟了。第一边缘算力便宜了几百块钱的开发板就能跑轻量推理不用把所有数据传回云端第二工业协议网关标准化了OPC UA over TSN的生态比几年前完整太多Modbus、Profinet、EtherCAT转OPC UA的网关都是成熟货架产品第三时序数据库和流处理框架下沉了以前要搭一套Hadoop集群才能做的事现在单机跑个轻量时序库加流计算引擎就够。注意不要一上来就追求大模型控制产线。工业现场对确定性和实时性的要求跟大模型的不确定性是天然冲突的。2026年真正能落地的是小模型做实时控制 大模型做辅助决策的混合架构。2. 整体架构设计与选型逻辑2.1 四层架构的划分依据我把整套系统分成四层这个划分不是拍脑袋而是按实时性要求和故障影响范围来切的。层级职责实时性要求典型技术栈现场层传感器采集、执行器驱动微秒到毫秒PLC、RTU、变频器边缘层协议转换、数据清洗、实时推理毫秒到百毫秒工业网关、边缘计算盒平台层模型训练、数据存储、任务调度秒到分钟时序库、训练框架、调度器应用层可视化、报警、报表、人机交互秒级Web前端、组态软件这么切的核心逻辑是越往下越不能停越往上越能容错。边缘层挂了产线可能停平台层挂了只是模型不更新控制还能靠上一版模型撑着。所以边缘层的代码要写得极其保守平台层可以激进一点。2.2 为什么边缘推理不用GPU很多人第一反应是边缘侧上GPU。我实测下来工业现场的推理负载跟互联网场景完全不是一个量级。一个软测量模型输入几十个特征输出一个回归值用INT8量化的树模型或者小型MLP在ARM Cortex-A72上单次推理不到5毫秒。上GPU除了增加功耗和故障点没有任何收益。真正需要算力的是训练和超参搜索这些放在平台层用一台带GPU的服务器就够了。边缘侧只做推理用CPU甚至MCU都能扛。这个分工想清楚了硬件成本能降一个数量级。2.3 通信中间件的选择边缘层和平台层之间怎么通信我试过三种方案。第一种是MQTT轻量、断线重连成熟适合数据上报。缺点是消息语义弱做请求-响应比较别扭。第二种是OPC UA语义完整、自带信息模型但实现重边缘侧跑完整栈有点吃力。第三种是gRPC性能好、接口清晰但需要自己处理断线重连和背压。我最后的方案是混合数据上报走MQTT因为现场网络抖动是常态MQTT的QoS机制能保证不丢关键数据模型下发和参数配置走gRPC因为这类操作频率低但要求可靠。两套通道各司其职比强行统一要稳。3. 核心环节的实操搭建3.1 现场数据采集与协议打通这一步是整个项目最容易翻车的地方。我在一个化工项目上光协议对接就花了两周。问题出在同一台设备的不同数据点可能走不同的协议——温度走Modbus RTU流量走HART设备状态走Profinet。你得先把这些异构协议统一到OPC UA。具体操作上我推荐用协议网关而不是自己写驱动。市面上的网关基本都支持Modbus转OPC UA、Profinet转OPC UA配置一下就能用。自己写驱动的坑在于不同厂商的Modbus寄存器映射千奇百怪字节序、浮点格式、地址偏移都可能不一样调试成本极高。采集频率怎么定我的经验是按控制回路的需求倒推。如果一个回路的响应时间是10秒那采集周期设1秒就够了没必要追求100毫秒。采集太快除了增加网络和存储压力对控制品质没有帮助。有个简单的判断方法采集周期应该小于被控对象时间常数的十分之一。# 一个典型的OPC UA采集客户端骨架 from opcua import Client import time client Client(opc.tcp://192.168.1.100:4840) client.connect() # 节点ID需要从网关的地址空间里查 temp_node client.get_node(ns2;sChannel1.Device1.Temperature) flow_node client.get_node(ns2;sChannel1.Device1.FlowRate) while True: temp temp_node.get_value() flow flow_node.get_value() # 这里做数据清洗和异常值过滤 if -50 temp 500: # 物理量程校验 publish_to_mqtt({temp: temp, flow: flow, ts: time.time()}) time.sleep(1)实操心得采集程序一定要加物理量程校验。我见过传感器故障输出一个离谱值直接把模型带偏的案例。量程校验是最便宜的数据质量防线。3.2 数据清洗与特征工程工业数据的特点是脏得很有规律。常见的脏数据有四种传感器漂移缓慢偏移、死值卡在一个数不动、尖峰瞬时跳变、缺失通信中断。这四种要分开处理。漂移用滑动窗口中位数减去长期均值来检测死值用方差为零判断尖峰用3σ准则或者更鲁棒的MAD中位数绝对偏差缺失就老老实实标记不要随便插值因为插值会引入虚假信息。特征工程这块工业场景跟互联网最大的区别是物理约束强。你不能随便做多项式组合因为组合出来的特征可能没有物理意义。我通常的做法是先做机理特征比如根据热力学公式算出的理论值再做统计特征滑动均值、方差、斜率最后才考虑让模型自己学交叉特征。import numpy as np def clean_signal(raw, window30, sigma3): 工业信号清洗去尖峰 标记死值 arr np.array(raw) # MAD去尖峰 med np.median(arr) mad np.median(np.abs(arr - med)) threshold sigma * 1.4826 * mad cleaned np.where(np.abs(arr - med) threshold, med, arr) # 死值检测 if len(np.unique(cleaned[-window:])) 1: return cleaned, True # True表示疑似死值 return cleaned, False3.3 模型训练与验证的工业特殊要求工业模型的验证跟互联网模型完全不是一回事。互联网看准确率工业看在最坏情况下的表现。一个模型平均误差很小但在某个工况下误差爆炸这个模型就是不能用的。我的验证流程是三步。第一步按时间切分而不是随机切分因为工业数据有时间相关性随机切分会造成数据泄漏。第二步分工况验证把数据按工况标签分组看每个工况下的误差。第三步对抗验证故意构造极端工况输入看模型输出是否在物理合理范围内。模型选型上我倾向于从简单模型开始。先用线性回归或者决策树建立基线如果基线够用就不上深度模型。工业现场对可解释性的要求很高一个能说清楚为什么这么决策的简单模型比一个黑箱深度模型更容易被现场工程师接受。3.4 边缘部署与实时推理模型训好之后要转成边缘能跑的格式。我常用的路线是PyTorch训练 → ONNX导出 → TensorRT或OpenVINO优化 → 边缘部署。如果是树模型直接导出成C代码或者用ONNX Runtime。部署时有个关键问题模型更新怎么做。我的方案是双缓冲——边缘侧同时保留两个模型版本新模型加载到备用槽验证通过后原子切换。这样更新过程中控制不中断出问题也能秒回滚。class ModelSlot: def __init__(self): self.active None self.standby None def load_standby(self, model_path): self.standby load_model(model_path) def switch(self): # 原子切换切换前做一次推理自检 test_input get_calibration_sample() if self.standby.predict(test_input) is not None: self.active, self.standby self.standby, None return True return False注意切换前一定要用标定样本做一次推理自检。我踩过的坑是模型文件传输损坏加载后输出全是NaN直接切上去控制就崩了。4. 常见问题与排查实录4.1 数据链路类问题问题一采集数据时有时无间隔性丢失。这个我遇到太多次了。排查顺序是先看网关的日志确认是网关没收到还是没发出去再看网络用抓包工具看有没有丢包最后看采集程序的缓冲区设置。八成的情况是采集程序的处理速度跟不上数据产生速度缓冲区满了就丢数据。解决办法是加一个带背压的队列处理不过来就阻塞采集而不是丢弃。问题二OPC UA连接频繁断开。先查心跳间隔设置。很多网关默认心跳是30秒但现场网络如果经过多层交换机可能20秒就超时了。把心跳调到10秒试试。如果还断检查是不是有防火墙在做连接老化把TCP keepalive打开。4.2 模型类问题问题三模型离线指标很好上线后效果差。这是最经典的坑。原因通常是训练数据和推理数据的分布不一致。训练时用的是历史数据推理时是实时数据中间可能隔了几个月工况已经漂移了。解决办法是建立在线监控持续比较推理输入的分布和训练分布的差异超过阈值就触发重新训练。问题四模型输出抖动大执行机构频繁动作。这是控制类模型特有的问题。模型每次推理都有微小差异如果直接下发执行机构就会来回动。解决办法是加输出滤波和死区——输出变化小于死区就不下发大于死区才动作。死区大小根据执行机构的机械寿命来定。问题现象可能原因排查方法解决措施数据间隔丢失缓冲区溢出看采集程序队列深度加背压机制连接频繁断开心跳超时抓包看断开时间缩短心跳间隔上线效果差分布漂移对比输入分布在线监控重训输出抖动推理噪声看输出方差加死区和滤波推理延迟高模型太大profile推理耗时量化剪枝4.3 系统集成类问题问题五边缘设备和平台层时间不同步。时间戳不一致会导致数据对齐错误模型训练时特征和标签错位。解决办法是全系统NTP对时边缘设备也配NTP客户端。如果现场没有NTP服务器用平台层服务器做时间源也行精度到毫秒级就够用。问题六模型更新后控制品质下降。先回滚再排查。排查时对比新旧模型的推理输出看差异在哪里。常见原因是新模型训练时用了不同的特征集但边缘侧的特征计算代码没同步更新。特征计算代码和模型必须版本绑定一起发布。实操心得我习惯在边缘侧加一个影子模式——新模型上线后先不控制只做推理并记录输出跟当前控制器的输出对比。跑够一定时间且差异在可接受范围内再真正切换。这个习惯帮我避免了好几次生产事故。5. 落地节奏与团队配置建议5.1 分阶段推进的节奏不要想着一次做完。我的建议是分三个阶段。第一阶段只做数据采集和可视化跑通链路让现场能看到数据。这个阶段不碰控制风险为零但能建立团队信心。第二阶段做软测量或预测性维护这类应用不直接控制输出的是辅助信息即使模型出错也不会造成生产事故。这个阶段用来打磨模型工程化能力。第三阶段才做闭环控制。这时候团队已经熟悉了数据链路和模型部署再上闭环风险可控。每个阶段之间留出至少一个月的稳定运行期不要赶。5.2 团队需要什么样的人最小可行团队是三个人。一个自动化工程师懂PLC和现场工艺负责数据采集和执行机构对接一个算法工程师负责模型训练和优化一个后端工程师负责平台层和数据管道。如果只有两个人算法和后端可以合并但自动化工程师不能省因为现场的事算法工程师搞不定。有个常见的误区是让算法工程师去搞现场对接。我试过效率极低。算法工程师不懂Modbus寄存器映射不懂电气柜接线去了现场就是抓瞎。专业的事交给专业的人。5.3 成本的大致构成硬件成本上边缘计算盒按每个控制回路一个算大概几千块平台层服务器一台带GPU的几万块网关按协议数量算每个几百到几千。软件成本主要是时序数据库和组态软件的授权这个弹性很大开源方案能省不少。人力成本是大头三个人半年的投入自己算。我在实际项目里的体会是最大的成本不是钱是时间。现场调试的时间往往超出预期因为现场环境跟实验室完全不一样。留足调试时间比省硬件钱重要得多。最后分享一个小技巧在实验室搭一套缩小版的仿真环境。用仿真PLC或者软件PLC模拟现场设备把整套链路先跑通。这样到了现场只需要处理真实的协议对接问题逻辑问题在实验室就解决了。这个习惯能让现场调试时间缩短一半以上。
AI工业控制系统落地实战：从数据采集到边缘推理的完整架构
1. 从零理解AI工业控制系统的真实边界1.1 这套系统到底在解决什么问题工业控制系统这个词听起来很重但拆开看其实就三件事采集现场数据、按规则做决策、把决策下发到执行机构。传统的PLC和SCADA已经把这三件事做了几十年稳定可靠那为什么还要加AI因为传统控制逻辑是if-else写死的遇到工况漂移、原料批次差异、设备老化这些慢变量要么频繁人工调参要么控制品质一路下滑。AI工业控制系统的核心价值就是让控制策略具备在线自适应能力——用数据驱动的方式去补偿那些写不进梯形图的隐性因素。我接触过的落地场景里最典型的是三类一是过程工业的软测量比如用温度、压力、流量去推断无法直接在线测量的成分浓度二是设备预测性维护从振动和电流信号里提前识别轴承劣化趋势三是复杂回路的先进控制用模型预测控制替代PID处理大滞后、强耦合的回路。这三类的共同点是传统方法能做但做不好AI能补上那块短板。适合读这篇内容的人我大致分两类。一类是自动化工程师手上有PLC和上位机想往上叠一层智能决策另一类是算法工程师模型训得不错但不知道怎么跟现场设备对接。这两类人中间有一条很深的沟我写这篇的目的就是把这条沟填上。1.2 2026年这个时间点的技术前提为什么现在谈这个比三年前靠谱三个条件成熟了。第一边缘算力便宜了几百块钱的开发板就能跑轻量推理不用把所有数据传回云端第二工业协议网关标准化了OPC UA over TSN的生态比几年前完整太多Modbus、Profinet、EtherCAT转OPC UA的网关都是成熟货架产品第三时序数据库和流处理框架下沉了以前要搭一套Hadoop集群才能做的事现在单机跑个轻量时序库加流计算引擎就够。注意不要一上来就追求大模型控制产线。工业现场对确定性和实时性的要求跟大模型的不确定性是天然冲突的。2026年真正能落地的是小模型做实时控制 大模型做辅助决策的混合架构。2. 整体架构设计与选型逻辑2.1 四层架构的划分依据我把整套系统分成四层这个划分不是拍脑袋而是按实时性要求和故障影响范围来切的。层级职责实时性要求典型技术栈现场层传感器采集、执行器驱动微秒到毫秒PLC、RTU、变频器边缘层协议转换、数据清洗、实时推理毫秒到百毫秒工业网关、边缘计算盒平台层模型训练、数据存储、任务调度秒到分钟时序库、训练框架、调度器应用层可视化、报警、报表、人机交互秒级Web前端、组态软件这么切的核心逻辑是越往下越不能停越往上越能容错。边缘层挂了产线可能停平台层挂了只是模型不更新控制还能靠上一版模型撑着。所以边缘层的代码要写得极其保守平台层可以激进一点。2.2 为什么边缘推理不用GPU很多人第一反应是边缘侧上GPU。我实测下来工业现场的推理负载跟互联网场景完全不是一个量级。一个软测量模型输入几十个特征输出一个回归值用INT8量化的树模型或者小型MLP在ARM Cortex-A72上单次推理不到5毫秒。上GPU除了增加功耗和故障点没有任何收益。真正需要算力的是训练和超参搜索这些放在平台层用一台带GPU的服务器就够了。边缘侧只做推理用CPU甚至MCU都能扛。这个分工想清楚了硬件成本能降一个数量级。2.3 通信中间件的选择边缘层和平台层之间怎么通信我试过三种方案。第一种是MQTT轻量、断线重连成熟适合数据上报。缺点是消息语义弱做请求-响应比较别扭。第二种是OPC UA语义完整、自带信息模型但实现重边缘侧跑完整栈有点吃力。第三种是gRPC性能好、接口清晰但需要自己处理断线重连和背压。我最后的方案是混合数据上报走MQTT因为现场网络抖动是常态MQTT的QoS机制能保证不丢关键数据模型下发和参数配置走gRPC因为这类操作频率低但要求可靠。两套通道各司其职比强行统一要稳。3. 核心环节的实操搭建3.1 现场数据采集与协议打通这一步是整个项目最容易翻车的地方。我在一个化工项目上光协议对接就花了两周。问题出在同一台设备的不同数据点可能走不同的协议——温度走Modbus RTU流量走HART设备状态走Profinet。你得先把这些异构协议统一到OPC UA。具体操作上我推荐用协议网关而不是自己写驱动。市面上的网关基本都支持Modbus转OPC UA、Profinet转OPC UA配置一下就能用。自己写驱动的坑在于不同厂商的Modbus寄存器映射千奇百怪字节序、浮点格式、地址偏移都可能不一样调试成本极高。采集频率怎么定我的经验是按控制回路的需求倒推。如果一个回路的响应时间是10秒那采集周期设1秒就够了没必要追求100毫秒。采集太快除了增加网络和存储压力对控制品质没有帮助。有个简单的判断方法采集周期应该小于被控对象时间常数的十分之一。# 一个典型的OPC UA采集客户端骨架 from opcua import Client import time client Client(opc.tcp://192.168.1.100:4840) client.connect() # 节点ID需要从网关的地址空间里查 temp_node client.get_node(ns2;sChannel1.Device1.Temperature) flow_node client.get_node(ns2;sChannel1.Device1.FlowRate) while True: temp temp_node.get_value() flow flow_node.get_value() # 这里做数据清洗和异常值过滤 if -50 temp 500: # 物理量程校验 publish_to_mqtt({temp: temp, flow: flow, ts: time.time()}) time.sleep(1)实操心得采集程序一定要加物理量程校验。我见过传感器故障输出一个离谱值直接把模型带偏的案例。量程校验是最便宜的数据质量防线。3.2 数据清洗与特征工程工业数据的特点是脏得很有规律。常见的脏数据有四种传感器漂移缓慢偏移、死值卡在一个数不动、尖峰瞬时跳变、缺失通信中断。这四种要分开处理。漂移用滑动窗口中位数减去长期均值来检测死值用方差为零判断尖峰用3σ准则或者更鲁棒的MAD中位数绝对偏差缺失就老老实实标记不要随便插值因为插值会引入虚假信息。特征工程这块工业场景跟互联网最大的区别是物理约束强。你不能随便做多项式组合因为组合出来的特征可能没有物理意义。我通常的做法是先做机理特征比如根据热力学公式算出的理论值再做统计特征滑动均值、方差、斜率最后才考虑让模型自己学交叉特征。import numpy as np def clean_signal(raw, window30, sigma3): 工业信号清洗去尖峰 标记死值 arr np.array(raw) # MAD去尖峰 med np.median(arr) mad np.median(np.abs(arr - med)) threshold sigma * 1.4826 * mad cleaned np.where(np.abs(arr - med) threshold, med, arr) # 死值检测 if len(np.unique(cleaned[-window:])) 1: return cleaned, True # True表示疑似死值 return cleaned, False3.3 模型训练与验证的工业特殊要求工业模型的验证跟互联网模型完全不是一回事。互联网看准确率工业看在最坏情况下的表现。一个模型平均误差很小但在某个工况下误差爆炸这个模型就是不能用的。我的验证流程是三步。第一步按时间切分而不是随机切分因为工业数据有时间相关性随机切分会造成数据泄漏。第二步分工况验证把数据按工况标签分组看每个工况下的误差。第三步对抗验证故意构造极端工况输入看模型输出是否在物理合理范围内。模型选型上我倾向于从简单模型开始。先用线性回归或者决策树建立基线如果基线够用就不上深度模型。工业现场对可解释性的要求很高一个能说清楚为什么这么决策的简单模型比一个黑箱深度模型更容易被现场工程师接受。3.4 边缘部署与实时推理模型训好之后要转成边缘能跑的格式。我常用的路线是PyTorch训练 → ONNX导出 → TensorRT或OpenVINO优化 → 边缘部署。如果是树模型直接导出成C代码或者用ONNX Runtime。部署时有个关键问题模型更新怎么做。我的方案是双缓冲——边缘侧同时保留两个模型版本新模型加载到备用槽验证通过后原子切换。这样更新过程中控制不中断出问题也能秒回滚。class ModelSlot: def __init__(self): self.active None self.standby None def load_standby(self, model_path): self.standby load_model(model_path) def switch(self): # 原子切换切换前做一次推理自检 test_input get_calibration_sample() if self.standby.predict(test_input) is not None: self.active, self.standby self.standby, None return True return False注意切换前一定要用标定样本做一次推理自检。我踩过的坑是模型文件传输损坏加载后输出全是NaN直接切上去控制就崩了。4. 常见问题与排查实录4.1 数据链路类问题问题一采集数据时有时无间隔性丢失。这个我遇到太多次了。排查顺序是先看网关的日志确认是网关没收到还是没发出去再看网络用抓包工具看有没有丢包最后看采集程序的缓冲区设置。八成的情况是采集程序的处理速度跟不上数据产生速度缓冲区满了就丢数据。解决办法是加一个带背压的队列处理不过来就阻塞采集而不是丢弃。问题二OPC UA连接频繁断开。先查心跳间隔设置。很多网关默认心跳是30秒但现场网络如果经过多层交换机可能20秒就超时了。把心跳调到10秒试试。如果还断检查是不是有防火墙在做连接老化把TCP keepalive打开。4.2 模型类问题问题三模型离线指标很好上线后效果差。这是最经典的坑。原因通常是训练数据和推理数据的分布不一致。训练时用的是历史数据推理时是实时数据中间可能隔了几个月工况已经漂移了。解决办法是建立在线监控持续比较推理输入的分布和训练分布的差异超过阈值就触发重新训练。问题四模型输出抖动大执行机构频繁动作。这是控制类模型特有的问题。模型每次推理都有微小差异如果直接下发执行机构就会来回动。解决办法是加输出滤波和死区——输出变化小于死区就不下发大于死区才动作。死区大小根据执行机构的机械寿命来定。问题现象可能原因排查方法解决措施数据间隔丢失缓冲区溢出看采集程序队列深度加背压机制连接频繁断开心跳超时抓包看断开时间缩短心跳间隔上线效果差分布漂移对比输入分布在线监控重训输出抖动推理噪声看输出方差加死区和滤波推理延迟高模型太大profile推理耗时量化剪枝4.3 系统集成类问题问题五边缘设备和平台层时间不同步。时间戳不一致会导致数据对齐错误模型训练时特征和标签错位。解决办法是全系统NTP对时边缘设备也配NTP客户端。如果现场没有NTP服务器用平台层服务器做时间源也行精度到毫秒级就够用。问题六模型更新后控制品质下降。先回滚再排查。排查时对比新旧模型的推理输出看差异在哪里。常见原因是新模型训练时用了不同的特征集但边缘侧的特征计算代码没同步更新。特征计算代码和模型必须版本绑定一起发布。实操心得我习惯在边缘侧加一个影子模式——新模型上线后先不控制只做推理并记录输出跟当前控制器的输出对比。跑够一定时间且差异在可接受范围内再真正切换。这个习惯帮我避免了好几次生产事故。5. 落地节奏与团队配置建议5.1 分阶段推进的节奏不要想着一次做完。我的建议是分三个阶段。第一阶段只做数据采集和可视化跑通链路让现场能看到数据。这个阶段不碰控制风险为零但能建立团队信心。第二阶段做软测量或预测性维护这类应用不直接控制输出的是辅助信息即使模型出错也不会造成生产事故。这个阶段用来打磨模型工程化能力。第三阶段才做闭环控制。这时候团队已经熟悉了数据链路和模型部署再上闭环风险可控。每个阶段之间留出至少一个月的稳定运行期不要赶。5.2 团队需要什么样的人最小可行团队是三个人。一个自动化工程师懂PLC和现场工艺负责数据采集和执行机构对接一个算法工程师负责模型训练和优化一个后端工程师负责平台层和数据管道。如果只有两个人算法和后端可以合并但自动化工程师不能省因为现场的事算法工程师搞不定。有个常见的误区是让算法工程师去搞现场对接。我试过效率极低。算法工程师不懂Modbus寄存器映射不懂电气柜接线去了现场就是抓瞎。专业的事交给专业的人。5.3 成本的大致构成硬件成本上边缘计算盒按每个控制回路一个算大概几千块平台层服务器一台带GPU的几万块网关按协议数量算每个几百到几千。软件成本主要是时序数据库和组态软件的授权这个弹性很大开源方案能省不少。人力成本是大头三个人半年的投入自己算。我在实际项目里的体会是最大的成本不是钱是时间。现场调试的时间往往超出预期因为现场环境跟实验室完全不一样。留足调试时间比省硬件钱重要得多。最后分享一个小技巧在实验室搭一套缩小版的仿真环境。用仿真PLC或者软件PLC模拟现场设备把整套链路先跑通。这样到了现场只需要处理真实的协议对接问题逻辑问题在实验室就解决了。这个习惯能让现场调试时间缩短一半以上。
