接到这个智能车间改造项目的咨询，对方开口第一句话是：“你们能不能先来车间看一眼，看完再谈价格。”当时我就知道，这家客户不是来比价的，是被之前的供应商伤过了。
事实也确实如此。客户那边前一年找过纯软件公司谈MES（制造执行系统），方案里排产、质量、绩效模块做得很漂亮，可一聊到设备数据怎么来，对方只能说“你们自己配采集设备，或者人工录入”。后来又找过一家偏硬件的集成商，PLC、传感器、看板大屏铺了一大堆，数据倒是采上来了，却堆在数据库里没人用，车间该手工抄表还是手工抄表。问题就出在“软硬件结合”这四个字上——软件的人不懂设备，硬件的人不懂数据，最后项目就烂在中间地带。
这篇案例分析，不打算讲什么宏大概念，就复盘这个智能车间改造项目从接洽、设计、实施到验收的全过程，包括选型逻辑、实施节奏、踩过的坑和沉淀下来的方法。给正在做车间数字化方案设计、或者计划把老车间往智能制造方向推的朋友一个参考。
1. 先搞清楚车间里到底有什么：需求不是“上MES”，是打通数据链路
1.1 现场摸底看到的三层断档
这个车间在某家做精密结构件的制造企业厂区内，覆盖注塑、冲压、装配、检测四类工序，一共40多台设备，属于典型的中小型机加车间。客户最初的需求表述很简短：“我要能看到每一台设备的实时状态，要能自动统计产量，不要再让我每天手工统计报表。”
听起来简单，真到现场就发现没那么简单。第一天摸底，我们把车间从东到西走了两遍，整理出三层断档：
第一层是设备层。40多台设备里，带PLC的勉强过半，而且品牌很杂，日系的、欧系的、国产的都有；剩下的是继电器控制的半自动设备，完全没有任何可读的数据接口。更麻烦的是，设备年头跨度极大，有些十几年的老冲床，控制柜里连说明书都找不到了。
第二层是执行层。班长每天巡线靠眼睛看，产量靠工人手写工单后拍照片发群里，设备一旦报警，操作工先扯嗓子喊维修，维修到了现场才能判断故障原因。中间浪费多少时间，没人统计过。
第三层是管理层。Excel表汇总每晚的生产数据，第二天上午才能知道前一天的实际产能。老板想看实时效率？做不到，顶多三天后看一张复盘表。
这三层之间没有任何自动通路，是典型的“设备是设备、系统是系统、人是人”的断档状态。
1.2 把客户的模糊需求翻译成技术需求
跟客户开需求对齐会的时候，客户方觉得“看设备状态”很容易，不就是装个传感器嘛。我们花了一下午，把一句话的需求拆成了一个需求清单：
- 每台设备必须有一个可采集的数据源：有PLC的优先走通讯协议，没有PLC的要加装IO采集模块或电流传感器；
- 设备状态必须定义清楚：运行、待机、故障、离线，四种状态要有明确的判据，不能靠猜；
- 产量统计不能只靠IO计数：冲压机和注塑机的单次动作不等于一件合格品，需要增加防错逻辑，比如连续多次空打不计产量；
- 断网不能丢数据：车间网络不可能100%稳定，边缘侧必须有本地缓存能力，保证断网期间数据不丢，恢复后自动补传。
这些需求翻译完，客户方设备负责人的表情才开始认真起来。他说之前那些方案谈不到这一层，供应商基本就是问“要几个点，装几个传感器”，从来不问设备本身能不能出数据、数据准不准。
顺带说一句，做这类项目，前期需求翻译的能力基本决定了项目毛利和风险。需求模糊，后面实施全是坑；需求拆得足够细，方案和报价才有锚点。
1.3 合同阶段三个经常被忽略的隐藏成本
这个阶段我们踩过一次亏，是在另一个项目上，所以这次商务谈判提前做了准备。智能车间改造的合同，最容易在三个地方漏项。
第一个是现场测绘费用。很多受访供应商报价时默认“来现场看看”是免费的，但真正深入的测绘要花大量人力——逐台设备开机验证IO点位、梳理通讯协议、记录控制柜走线，两三个人在车间泡一周很正常。这次客户比较爽快，愿意把测绘作为一个正式阶段单独立项付费，我们才敢把方案做扎实。
第二个是停产窗口成本。老设备加装采集模块、更换PLC程序、联调测试，都需要停机。客户产线是两班倒，设备停机一个小时损失可观。我们在方案里把每台设备的停机时间控制在3-4小时，并在合同里注明：涉及生产停机的作业必须提前一周报备计划，由生产部安排窗口期。这点不写清楚，后面一定会扯皮。
第三个是售后响应成本。设备联网之后，手机端弹出“XX设备离线”，客户第一反应就是找项目方。我们的合同明确了响应等级：一般问题48小时内远程处理，设备故障24小时内到场，产线停机的重大故障4小时内响应。同时，把售后值守成本按“每周留半天驻场”的基准做进了报价。很多同行觉得智能车间改造是一次性买卖，实际上售后才是长期成本的大头。
2. 软硬件选型：为什么最终敲定了这套组合方案
2.1 硬件层的三个关键决定
选型阶段，内部开了两次评审会，把方案推翻了三轮。最后定下来三条原则，这三条原则后来被验证是对的。
第一条原则：老的PLC能不动就不动，新设备统一选带网口的国产PLC。老设备虽然品牌杂，但只要还能跑、能远程读写寄存器，就不要去换PLC，因为换PLC意味着重新写控制程序，风险极高。新增的两台注塑机，我们统一要求买带以太网口的型号，避免后期再挂一层采集模块。
第二条原则：半自动设备不硬接PLC，直接加IO采集模块和电流互感器。继电器控制的设备没有通讯协议，硬要接控制器属于自找麻烦。我们采用两个信号源组合判断：电流互感器检测主电机是否通电，IO模块接设备的启动信号、循环次数计数信号、报警信号。这种方式不侵入原设备控制逻辑，改造安全性高，工人也容易理解。
第三条原则：边缘网关选型看重双网卡、断点续传和支持主流协议。现场有两类网络必须隔离（后面会细说），网关必须有双网口。断点续传是硬性要求，车间网络抖动太常见了，没有本地缓存就是灾难。协议支持上，Modbus TCP、OPC UA、Modbus RTU三样必须有，这三样覆盖了市面上80%以上的存量设备接口。
硬件数量测算上有一个简单公式：先统计点位，再算网关数量。以这台注塑机为例，需要采集运行状态点、待机状态点、故障报警点、单次循环计数点，大概8-12个IO点；冲压机多一些，在15-20个点。整个车间做完点位表，一共410个采辑点。单台边缘网关的建议带载量是64个点位，但我们按带载率不超过70%来规划，预留扩容余量，所以算下来需要8台网关，而不是理论上的7台。多出来的这1台网关，让后期加设备时没怎么动网络架构。
2.2 软件层：轻量MES加自研采集端，不追求大而全
客户一开始想要的是一套大而全的MES，最好连排产、绩效、质量追溯都包了。但看过车间实际的管理水平之后，我们建议先把地基打好，MES只选四个核心模块：生产工单管理、报工管理、设备状态监控、异常报警管理。排产和质量追溯是二期的事，一上来就铺摊子，运营能力跟不上，系统必然沦为摆设。
这个建议客户方起初是犹豫的，他们的IT负责人觉得一次到位更省事。我们算过一笔账：大MES光实施周期就要6个月起步，而且业务部门根本来不及适应流程变化；轻量MES三个月能上线，等大家把设备数据用起来、尝到甜头了，二期再上排产模块，成功率反而高。最后客户认可了这个节奏。
数据采集端我们选择了自研，而不是直接买商业采集平台，理由有两条：一是客户的设备种类杂、点位逻辑特殊，商业平台要定制开发的话费用翻倍；二是自研采集端可以完全掌控后续的维护和迭代，不会被第三方卡脖子。采集端的核心逻辑不复杂：每2秒轮询一次边缘网关，拉取设备状态和计数，写入消息队列，再异步同步到MES数据库。这里有个细节，轮询频率不是越快越好。开始我们设成了500毫秒，结果发现有的老PLC通讯模块被高频请求拖慢了，直接影响设备正常控制——PLC的主要职责是控制设备，不是陪采集系统聊天。后来统一改成2秒轮询，数据粒度对产量统计完全够用，设备侧也恢复稳定。
2.3 接口兼容性：别指望统一协议，先摸清存量底牌
选型阶段最花时间的是摸设备协议。一圈摸底下来，真正能一口气走OPC UA的设备不到五分之一，剩下的要么是Modbus TCP，要么是Modbus RTU，还有一批老设备完全没有通讯手册。对于没有手册的，我们采用了两种办法：一是查PLC程序里的寄存器分配表，很多老设备的程序还在，对应地址能读出数据；二是用逐地址轮询试读，从常见地址段扫一遍，看哪些寄存器返回的数据变化规律和现场动作吻合——这个方法比较土，但在两台进口老设备上确实管用了，省掉了两套采集模块的钱。
不追求统一协议，是这次选型过程中很重要的一条经验。很多方案里强调“一个标准协议打通所有设备”，现实情况是存量设备根本做不到，硬统一要么花大钱改造，要么改造失败。我们的原则是：能用协议走协议，不能用协议就加硬件，最终只要能进边缘网关的数据都是好数据。
3. 90天的实施过程：从现场测绘到并行上线
3.1 第一周：图纸和现实的对账
进场第一周，我们做的不是安装，是逐台设备对账。设备科的台账上写着41台设备，实际车间里数出来是43台——有台闲置的清洗机被挪到了角落，台账没删；还有一台空压机被当成了冲压设备的管理节点，纯属台账混乱。
更麻烦的是控制柜的接线。图纸上标注的PLC输入输出点，在现场有三分之一对不上号。有两台设备的控制柜在历次维修中被改过线，图纸没更新，我们只能拿着万用表一段一段测线，把所有点位重新做了一遍标签。这项工作不起眼，但省了后面联调阶段大量的排错时间。所以这次项目我们把“现场点表核对”单独列成了一个交付物，责任到人，不做完不许进安装环节。
同期做的是工控网络布局。车间里大功率设备频繁启停，电压冲击和电磁干扰对网络设备很不友好。第一次采购的普通交换机，在离冲压机5米的位置频繁死机重启——电柜一开门，交换机就跟着魔术灯闪烁，这肯定不行。我们换成了工业级交换机，带宽温设计和更高的电磁兼容等级，之后整个实施周期内再没有出现过无故重启。
3.2 网络方案：管理网和控制网必须物理隔离
网络规划是这次项目中后期运营最顺利的一个环节，因为一开始就做了正确的隔离。车间一共划分成三个网段：办公管理网、车间控制网、数据采集网。办公管理网走日常办公和MES终端，车间控制网连接PLC和关键控制设备，数据采集网专门给边缘网关和采集服务器用，三类流量互不串扰。
为保证安全隔离要求，两个网段在二层物理上直接分开，用一台工业路由做三层转发，用访问控制列表设置白名单。控制类流量只有特定端口放行，采集流量只允许网关卡和采集服务器之间通讯。这样即使办公电脑中了病毒，也不至于穿透到控制网络。
车间里AGV（自动导引车）走无线扫码的方式，我们最初把生产数据采集也搭在了同一个无线网络上，结果联调时发现信号飘移太厉害，大车一过就丢包，断点续传功能倒是正常，但数据实时性被拖到了10秒以上，客户看板刷新明显卡顿。后来临时决定在关键工位的边缘网关改用有线网络，通信质量才稳定下来。经验是：车间里能用有线就用有线，尤其是固定设备；无线方案留给移动设备，别贪图省布线而牺牲可靠性。
3.3 联调阶段最硬的两场仗
第一场仗是设备状态误判。系统跑了一周，客户看着状态看板皱眉：“这两台注塑机明明在待机，系统显示运行，你们这数据准不准？”
排查发现，问题出在PLC程序本身的逻辑上。有些设备在待机模式下，PLC内部仍有一个“运行”信号保持置位，这是生产工艺上的“零位待机”，设备电机没有转，但信号状态跟运行时一样。如果只按单个信号判断，待机和运行就混在一起了。我们在采集端加了一套状态判定逻辑：把“电机电流大于阈值”作为运行的必要条件，同时引入“循环计数是否有增量”作为辅助判据。改造后，待机识别的准确率从82%提升到了99%以上。
第二场仗是历史数据补传导致数据库压力飙升。车间网络偶尔断开，边缘网关本地缓存数据，等网络恢复后一下子把几小时的数据全部传上来，采集服务器瞬间出现写库排队。开始以为是服务器性能不够，后来排查是补传逻辑没有加限速和分批处理。我们在采集端加了“补传限速”模块，每秒钟最多补传500条记录，并对历史数据做了批量插入优化。这个坑很小，影响面却不小，好在联调阶段就暴露了，上线后没再出现。
3.4 上线切换：并行期管理决定了项目成败
系统正式上线并没有“一刀切”。我们和客户约定了1个月的并行期——新系统自动采集数据，但现场纸质工单照旧填写。这一个月不是让工人偷懒，而是用来验证数据的准确度和查漏补缺。
并行期暴露了一个有意思的问题：系统统计的小时产量比工人手写报表低了12%。工人第一反应是系统有问题，但我们现场盯了两天，发现是手写报表存在虚报——晚班最后半小时的产量经常被记超，因为工长希望白班看起来效率不够高，给自己留点余地。这个发现很敏感，我们没有当着工人的面说是数据造假，而是把对比数据拿给车间主任看，建议以系统为准，手写报表逐步取消。车间主任也认可了系统的准确性。
并行期还做了三件培训：操作工学会在设备异常时查看屏幕弹窗和扫码报工；维修班学会看设备的离线告警和故障代码；统计员学会从MES后台导出报表，不再用Excel手工合并。这三类人接受新系统的方式完全不同：操作工在乎好不好用、麻不麻烦；维修班在乎报警准不准、处理流程顺不顺；统计员在乎导出格式能不能直接用。培训做得细，后期推广阻力小很多。
4. 交付之后复盘：哪些坑不该再踩，哪些方法值得沉淀
4.1 这次项目里最典型的三个坑
第一个坑是数据质量治理被轻视了。项目验收时数据准确率达到99.5%，但运营一个月后出现了下滑，部分原因是现场设备在调整参数后，信号的判据没同步维护。比如某台注塑机改了模具，循环时间变了，原来判断运行状态的电流阈值不再适配，系统开始误报。数据质量不是上线那一刻的指标，而是运营过程中持续维护的指标。后面我们在客户方设立了一个数据专员岗位，每周核对一次状态看板与实际生产记录，发现偏离及时调整判据。
第二个坑是设备离线问题的责任归属。初期的设备离线，三分之一是网络问题，三分之一是边缘网关电源松动，剩下的是设备检修时主动断电但系统没有对应流程。客户一开始觉得“离线就是你们系统的问题”，我们派人到现场一看，发现是维修工拔了设备电源没通知任何人。后来我们在系统里加了“离线分类”功能：检修计划内的离线（有工单记录）、网络中断离线、设备故障离线，三种状态用不同颜色标识。责任边界清楚了，扯皮也就少了。
第三个坑是验收标准里没有明确数据一致性校验规则。我们和客户对账时，发现产量数据的核对方式有歧义：标称产量是按冲压次数换算件数，但合格品数量要剔除废品。如果MES显示的是毛产量，报表和生产实际对不上。解决方案是增加“合格品率折算”逻辑，并在第三方检验报告里明确口径。这里建议所有做类似项目的读者，验收标准里务必写明数据口径和校验规则，避免验收的时候来回扯。
4.2 项目组织：工艺、设备、IT三方怎么协同不打架
智能车间改造项目，软件上了之后最难的往往不是技术，是组织协同。这个项目我们建立了每周一次的三方例会机制，参会人包括客户方的设备科负责人、生产车间主任、IT负责人和我们的项目经理。例会只讨论三件事：本周影响生产的异常事件、下周的停机改造计划、数据口径的变更和新增需求。
这个例会机制帮了大忙。有一次设备科想调整一台冲压机的安全光栅信号接线，如果直接改，采集系统会误报设备故障。因为IT、设备、生产在例会上提前对过计划，改造排在周末进行，并且由我们的实施人员在旁配合验证数据，全程没影响生产秩序。
项目组织上还有一条经验：必须设置一个“系统运维接口人”。客户方指定一名懂设备又愿意学系统的工程师作为接口人，平时负责数据质量的日常巡检、点位表变更和维护申请。这个人帮我们挡掉了大量非计划内的需求变更，也让客户有自己的持续运维能力，不至于项目一撤就转不起来。
4.3 项目沉淀下来哪些可直接复用的交付模板
项目结束之后，我们把过程资产整理成了三份可复用的模板，分别是需求调研清单、实施检查表和验收清单。
需求调研清单覆盖设备台账核对、点位表、协议摸底、网络现状、生产流程、异常处理流程等八大类、六十多个检查项。下次接类似的车间改造项目，直接拿着清单逐项过，几个小时能完成基础信息的初步收集。
实施检查表则规定了从进场勘测、点位核对、网络部署、网关安装、接线验证、系统配置、联调到培训的每个环节的交付标准，结合项目定制成电子表格，每一步都必须有责任人签字确认。
验收清单里，除了常规的功能验收项，添加了并线期数据对比报告、数据一致性校验规则、设备状态判据文档。这三份模板到现在还在我们后续几个类似项目里使用，出活儿效率和实施质量都要稳定不少。
我自己回头来看，这个项目能顺利验收，核心不在技术多先进，选型多豪华，而是把需求翻译清楚了、把软硬件的接口关系理清了、把组织协同机制做扎实了。智能车间改造听起来是技术活，最后拼的恰恰是细节和流程的掌控力。如果你正准备接类似项目，建议先别急着报价，去产线蹲一天，设备能不能出数、工人愿不愿意用、车间主任关心什么指标，这些比方案里的拓扑图重要得多。
