企业官网建设流程全解析

1. 非标设备联网这件事，为什么总在项目验收前夜才被想起

做非标自动化这行十来年，我见过太多项目在机械装配、电气调试、PLC程序跑通之后，所有人都觉得"就差交付了"，结果卡在最后一步——客户问了一句："这台设备的数据能不能接到我们MES里？"现场瞬间安静。

这不是个别现象。非标设备行业有个根深蒂固的习惯：先解决"能不能动"，再考虑"能不能看"。机械设计、电气选型、PLC编程、HMI组态，这些环节都有成熟的流程和验收标准，但"联网"这件事往往被归到"后面再说"的篮子里。等到设备拉到客户现场，才发现控制柜里那台跑了三年的老PLC只有一个RS232串口，触摸屏是单机版不支持以太网，变频器走的是私有协议，伺服驱动器连手册都找不到了。

传统运维的痛点在这个节点集中爆发。设备在客户手里，出了问题只能打电话描述现象，工程师凭经验猜故障点，带一堆可能用不上的备件上门，到了现场发现猜错了，再回来取。一台设备停一天，客户产线损失可能几万到几十万，这笔账最后还是要算到设备商头上。更麻烦的是，很多非标设备是单台定制，没有批量，没有远程诊断手段，售后成本高得离谱，有些项目甚至售后阶段就把利润吃光了。

物联网联网要解决的核心问题，就是让设备"会说话"。不是简单地加个4G模块传几个温度值，而是要让运维人员在不拆柜、不断电、不打扰生产的前提下，知道设备当前在干什么、历史发生了什么、接下来可能出什么问题。这件事对非标设备来说比标准设备更迫切，因为非标设备没有批量摊薄成本，每一台的运维效率都直接决定项目盈亏。

下面我从实际项目出发，把非标设备物联网联网这件事拆开讲清楚。不管你是刚入行的电气工程师，还是做了多年非标项目的负责人，或者正在被售后问题折磨的运维人员，都能从里面找到可以直接用的思路和方案。

2. 传统非标设备运维的四个死结，每一个都在吃掉利润

2.1 故障描述靠电话，信息衰减从第一句话就开始了

非标设备的现场操作工往往不是电气专业人员。设备报警了，他看到的可能是一个红色指示灯闪烁，或者HMI上弹出一行"轴2位置偏差过大"。打电话给设备商售后，描述变成"机器不动了，有个灯在闪"。售后工程师再转述给电气工程师，变成"客户说设备启动不了"。电气工程师凭经验判断可能是伺服报警，带了一个伺服驱动器上门，到了现场发现是接近开关被铁屑糊住了。

这个信息衰减链条每经过一个人就损失一层细节。我统计过我们团队过去两年的售后工单，超过60%的上门服务是因为电话里无法准确判断故障点，其中又有将近一半到了现场发现带的备件不对。一次上门的人工、差旅、备件成本加起来，少则两三千，多则上万。如果设备在偏远地区，这个数字还要翻倍。

物联网联网之后，设备报警的瞬间，PLC的故障代码、伺服驱动器的报警号、关键传感器的实时值、报警前后几分钟的电流曲线，全部自动上传到云端。售后工程师打开手机就能看到"轴2伺服驱动器报AL.32，过载保护，报警时电流达到额定值的180%，持续时间1.2秒"。这时候再决定带什么备件、要不要远程指导客户复位，准确率完全不一样。

2.2 设备状态是黑盒，预防性维护无从下手

非标设备有个特点：机械结构往往是定制的，运动部件多，气缸、电机、皮带、链条、凸轮机构混在一起。这些部件的磨损是有规律的，但传统设备不记录任何运行数据，维护全靠"坏了再修"或者"定期换"。

定期换的问题在于，你不知道设备实际跑了多少个小时、负载率是多少、启停频率有多高。一台设计寿命五年的设备，如果客户是三班倒24小时跑，可能两年就到大修期了；如果客户是单班偶尔用，五年下来机械磨损还很轻微。用同一个时间周期去维护，要么过度维护浪费钱，要么维护不足导致突发停机。

我做过一个注塑机辅机项目，机械手抓取机构的导轨滑块，原厂建议每6个月换一次。客户是24小时连续生产，我们通过物联网模块记录了滑块的运行次数和每次运动的电流曲线。数据积累三个月后发现，滑块电流在运行到第80万次左右开始出现微小上升趋势，到第95万次时上升斜率明显变大。我们把这个点设为预警阈值，实际更换周期从固定的6个月变成了"80万次或电流上升超过15%"，既避免了突发卡死，又比原来少换了将近一半的滑块。

2.3 售后响应慢，客户满意度靠人情维持

非标设备的客户往往也是制造企业，他们的产线停不起。设备出问题，客户老板的电话直接打到设备商老板那里，压力层层传递到售后工程师。但售后工程师手里可能同时压着五六个项目，每个项目都在不同的城市，物理上不可能同时响应。

传统做法是"谁离得近谁先去"，或者"哪个客户催得急先去哪个"。这种调度方式完全没有数据支撑，客户满意度全靠售后工程师的个人能力和态度。遇到脾气好的客户，晚半天没关系；遇到产线停不起的客户，晚一小时就是事故。

联网之后，设备报警自动生成工单，工单里包含故障等级、影响范围、建议处理方式。售后主管可以根据工单的紧急程度和工程师的地理位置做调度，而不是凭感觉。更重要的是，很多故障可以通过远程指导客户操作工复位或切换备用模式，根本不需要上门。我们统计过，联网之后大约35%的报警可以通过远程指导解决，上门率下降了三分之一。

2.4 设备商和客户之间没有数据纽带，续约和升级全靠喝酒

非标设备做完一单就是一单，设备交付之后，设备商和客户之间除了售后维修，几乎没有其他连接。客户下一台设备要不要找你，取决于关系好不好、价格合不合适，而不是你的设备运行数据证明了你有多可靠。

物联网联网之后，设备商可以给客户提供月度运行报告：设备利用率多少、故障次数多少、平均修复时间多少、能耗多少。这些数据对客户的生产管理有价值，对设备商的续约和升级也有价值。客户看到你的设备一年只停了两次，每次修复不到两小时，下一台设备还会考虑别人吗？

这四个死结，每一个都指向同一个结论：非标设备不联网，运维就是盲人摸象，成本不可控，质量不可控，客户关系也不可控。

3. 非标设备联网和标准设备联网，根本是两码事

3.1 标准设备联网是"批量复制"，非标设备联网是"单台定制"

标准设备比如注塑机、空压机、电梯，厂家有成熟的物联网方案，控制器是自研的或者固定型号的，通信协议是统一的，联网模块是标配的。一台设备联网调试好，后面一万台都是一样的配置，边际成本几乎为零。

非标设备完全不是这个逻辑。每一台设备的PLC型号可能不同，伺服品牌可能不同，仪表通信协议可能不同，甚至同一台设备里混着三四个品牌的控制器。你不可能为每一台非标设备单独开发一套物联网系统，成本受不了。你需要一套"能适配多种协议、能灵活配置点位、能快速部署"的方案。

这就决定了非标设备联网不能照搬标准设备的做法。标准设备可以要求所有供应商必须支持某个协议，非标设备只能"有什么协议用什么协议，实在不行加转换模块"。

3.2 非标设备的通信接口现状：新旧混杂，协议林立

我做过一个统计，我们团队近三年交付的非标设备里，PLC品牌分布大概是：三菱FX系列占30%，西门子S7-200 SMART占25%，欧姆龙CP系列占15%，台达和信捷合计占20%，剩下10%是各种国产小众品牌和早期型号。这些PLC的通信能力差异巨大。

三菱FX3U只有一个RS422编程口，要联网得加FX3U-ENET-ADP以太网模块或者FX3U-485BD通信板。西门子S7-200 SMART自带以太网口，支持S7协议，相对好搞。欧姆龙CP1E只有USB和RS232，联网要加CP1W-CIF41以太网模块。台达DVP系列有RS232和RS485，部分型号有以太网。

伺服驱动器的情况更复杂。三菱J4系列支持RS422和USB，松下A6系列支持RS485和USB，台达ASDA-B2支持RS485和CANopen，汇川IS620支持RS485和EtherCAT。这些驱动器的通信协议大多是厂家私有的，要读报警号和电流值，得用厂家提供的通信协议手册逐条解析。

仪表类设备相对规范一些。温控器、流量计、压力变送器大多支持Modbus RTU over RS485，少数支持Modbus TCP。但问题是，一台非标设备上可能有五六个仪表，每个仪表的Modbus寄存器地址定义都不一样，需要逐个查手册配置。

3.3 联网方案选型：网关、DTU、边缘计算盒子怎么选

面对这种混乱的接口现状，非标设备联网的硬件方案大致分三类：

第一类是协议转换网关。比如把RS485的Modbus RTU转成Modbus TCP或者MQTT，把三菱FX的编程口协议转成以太网协议。这类网关的优点是便宜、简单、即插即用，缺点是功能单一，只能做协议转换，不能做数据缓存、边缘计算、断网续传。适合点位少、逻辑简单的场景。

第二类是工业DTU。DTU本质是一个透传模块，把串口数据通过4G网络透传到服务器。优点是部署快、成本低，缺点是透传模式下数据没有结构化，服务器端需要自己解析协议，而且DTU通常不支持本地缓存，断网期间的数据就丢了。适合临时监控或者对数据完整性要求不高的场景。

第三类是边缘计算网关。这类网关有操作系统（通常是Linux），支持多种协议驱动，可以在本地做数据采集、协议解析、边缘计算、数据缓存、断网续传，然后通过MQTT或者HTTP上传到云平台。优点是功能强大、灵活，缺点是需要配置和调试，成本比前两类高。适合点位多、逻辑复杂、对数据完整性要求高的场景。

我的经验是，非标设备联网优先选边缘计算网关。原因很简单：非标设备的通信协议太杂，边缘网关可以在一台设备上同时接RS485、RS232、以太网、CAN等多种接口，内置的协议驱动可以覆盖大部分主流PLC和仪表。而且边缘网关支持本地脚本，可以在设备端做数据预处理，比如把PLC里的整数转换成工程量、把报警位解析成文字描述、把高频采集的数据做降频处理再上传。这些工作在服务器端做也可以，但会增加网络流量和服务器负载。

选边缘网关的时候重点看几个参数：支持的协议驱动数量、是否支持脚本编程、本地存储容量、断网续传机制、工作温度范围、防护等级。非标设备的电柜里温度可能到50度以上，网关的工业级温度范围至少要-20到70度。电柜里粉尘和振动也要考虑，防护等级至少IP30，最好IP40以上。

4. 从一台老设备改造入手：联网实施的具体步骤

4.1 第一步：盘点设备里所有需要联网的数据源

联网改造最忌讳的就是"先买网关再想接什么"。正确的顺序是先盘点数据源，再选网关。

盘点的内容包括：PLC的品牌型号、通信接口类型和数量、支持的协议；触摸屏的品牌型号、是否有以太网口、是否支持数据转发；伺服驱动器的品牌型号、通信接口、是否支持报警读取；变频器的品牌型号、通信接口、是否支持运行状态和电流读取；仪表类设备的品牌型号、通信协议、寄存器地址表；其他需要监控的传感器，比如温度、压力、流量、液位、接近开关等。

盘点的时候要特别注意：有些老设备的PLC通信口已经被触摸屏占用了，如果要同时接网关和触摸屏，需要确认PLC是否支持多主站或者加通信扩展板。有些伺服驱动器的通信口是调试口，正常运行时不能占用，这种情况只能通过PLC间接读取伺服状态，或者加电流互感器直接测电机电流。

我一般会做一个表格，把每个数据源的品牌型号、接口类型、协议、需要读取的数据点、读取频率、备注都列清楚。这个表格是后续选型和配置的基础。

4.2 第二步：确定数据采集频率和上传策略

数据采集频率不是越高越好。采集频率越高，网关的CPU负载越大，网络流量越大，云端存储成本越高。非标设备的运维监控，大部分数据不需要毫秒级采集。

我的经验值是：设备运行状态（运行、停止、报警）变化时上报，或者每30秒上报一次；关键工艺参数（温度、压力、速度）每5到10秒采集一次，变化超过阈值时立即上报；电流、电压等模拟量每1到2秒采集一次，用于故障录波；报警事件立即上报，并附带报警前后各30秒的相关数据。

上传策略要考虑网络状况。4G网络的稳定性和带宽都不如有线网络，如果设备在信号不好的地方，上传频率太高会导致数据堆积。边缘网关的断网续传功能这时候就很重要：网络正常时实时上传，网络断开时数据存本地，网络恢复后按时间顺序补传。

还有一个细节：很多非标设备的电柜里没有稳定的电源，网关的供电要从PLC的24V电源取。如果PLC电源容量不够，网关可能会因为供电不足而重启。我遇到过好几次网关随机重启的问题，最后发现是24V电源的纹波太大，加了一个滤波电容就好了。所以选网关的时候要看功耗，一般边缘网关功耗在5到10瓦，PLC的24V电源至少要留出20%的余量。

4.3 第三步：网关配置和协议对接的实操细节

网关配置的核心工作是协议对接。以最常见的Modbus RTU转MQTT为例，配置流程大致是：

首先在网关的串口配置里设置波特率、数据位、停止位、校验位，这些参数必须和PLC或仪表的串口参数完全一致。我见过很多配置失败的情况，最后发现是校验位设错了，PLC是偶校验，网关设成了无校验。

然后在网关的协议驱动里选择Modbus RTU，配置从站地址和寄存器映射表。寄存器映射表需要查PLC或仪表的通信手册，把每个需要读取的数据点的寄存器地址、数据类型、字节序、缩放因子都填进去。这里最容易出错的是字节序和缩放因子。比如一个32位浮点数，PLC里可能是高字在前，也可能是低字在前，网关里要对应设置。缩放因子是10的多少次方，也要和PLC程序里的定义一致。

配置完成后，用网关的调试工具先读一次数据，确认每个点的值都正确。这一步不能省，我见过太多人配置完直接上线，结果数据全是错的，排查起来更麻烦。

协议对接完成后，配置MQTT上传。需要设置服务器地址、端口、客户端ID、用户名密码、发布主题、数据格式。数据格式建议用JSON，可读性好，云端解析方便。主题命名要有规律，比如device/{设备编号}/data、device/{设备编号}/alarm、device/{设备编号}/status。

4.4 第四步：云端数据存储和报警规则设置

云端的事情可以简单也可以复杂。简单的做法是用一个MQTT服务器加一个时序数据库，比如EMQX加InfluxDB，再写一个简单的Web界面展示数据。复杂的做法是用完整的工业物联网平台，带设备管理、数据可视化、报警管理、工单系统、报表导出。

对于非标设备来说，我建议从简单方案起步。先把数据存下来，把报警推出去，把历史曲线画出来。这三个功能能解决80%的运维痛点。等用了一段时间，再根据实际需求增加功能。

报警规则设置有几个关键点：报警阈值要能远程修改，不能写死在网关里；报警要有分级，比如"警告"和"故障"分开，警告只记录不推送，故障立即推送；报警要有延时确认，避免瞬时波动误报；报警恢复后要自动清除，不能一直挂着。

推送方式建议用企业微信或者钉钉的机器人，配置简单，手机能收，还能@相关人。短信推送成本高，而且容易被当成垃圾短信。电话推送只适合最高等级的故障，比如设备完全停机且影响产线。

5. 联网之后运维到底变了什么：三个真实场景的对比

5.1 场景一：伺服过载报警的处理时间从4小时缩短到20分钟

去年我们给一个客户做了两台非标装配设备，设备上用了四台台达ASDA-B2伺服驱动器。设备交付三个月后，客户打电话说其中一台设备的第三轴偶尔报警，报警后复位又能继续跑，但一天要报好几次。

传统做法：售后工程师电话里问不清楚，只能上门。到了现场，伺服报警已经复位了，查不到历史报警记录。只能让客户盯着，等下次报警时拍照。客户操作工不可能一直盯着，等了三天才拍到一张报警照片，显示AL.09，位置偏差过大。工程师分析可能是机械卡顿或者编码器干扰，带了新的伺服驱动器和编码器线上门，换了之后还是偶尔报警。最后折腾了一个星期，发现是机械导轨的润滑不够，导致偶尔卡顿。

联网之后：伺服驱动器的报警号、报警时的位置偏差值、电机电流、运行速度全部上传到云端。客户打电话的时候，我直接打开手机看历史报警记录，发现AL.09报警时位置偏差值达到0.5mm，正常运行时偏差在0.02mm以内。同时电流曲线显示报警瞬间电流有一个尖峰。这两个数据结合起来，基本可以判断是机械卡顿而不是电气问题。我让客户先检查导轨润滑，客户加了润滑油之后报警消失。整个过程从打电话到解决，20分钟。

这个场景的关键不是联网本身，而是联网之后能拿到"报警瞬间的上下文数据"。传统方式只能看到报警号，联网之后能看到报警前后几秒的电流、位置、速度曲线，故障定位的准确率完全不一样。

5.2 场景二：远程修改PLC参数，避免了一次跨省出差

有一个项目在北方，设备运行了半年，客户反映生产节拍比刚交付时慢了10%。按照传统做法，节拍变慢可能是机械磨损、气压不足、传感器位置偏移、PLC程序参数漂移等多种原因，需要工程师上门逐一排查。

联网之后，我先远程读取了设备的运行数据。发现设备的气缸动作时间比刚交付时增加了0.3秒，其他动作时间基本没变。再查气压数据，发现客户的气源压力从0.6MPa降到了0.5MPa。基本可以判断是气压不足导致气缸动作变慢。

我让客户检查空压机和气路，发现是过滤器堵塞导致压力下降。客户更换过滤器后，气压恢复到0.6MPa，但节拍还是没有完全恢复。我又远程读取了PLC里的气缸动作延时参数，发现客户之前为了应对气压不足，让操作工在HMI上把延时参数调大了。我把参数改回原始值，节拍恢复正常。整个过程没有出差，省了至少两天时间和两千多块差旅费。

这个场景说明一个问题：非标设备的很多"故障"其实是参数漂移或者外部条件变化，不需要换件，只需要远程调整。联网之后，这类问题的处理成本几乎为零。

5.3 场景三：设备利用率报告帮客户发现了产线瓶颈

有一个客户买了我们两台设备，用了半年之后跟我们抱怨说设备效率不高。我们通过物联网模块导出了两台设备的运行数据，做了一份利用率报告。

报告显示：一号设备每天实际运行时间只有5.2小时，二号设备每天运行7.8小时。一号设备的待机时间特别长，而且待机时间集中在下午。进一步分析发现，一号设备的下游工序在下午经常缺料，导致一号设备做出来的半成品堆积，操作工只能停机等料。

客户看到这份报告之后，调整了下游工序的排产，一号设备的利用率从5.2小时提升到了7.5小时。客户老板后来跟我们说，这份报告的价值比设备本身还大，因为他之前根本不知道瓶颈在哪里。

这个场景说明，物联网联网的价值不只是运维，还能帮客户优化生产。设备商从"卖设备"变成"卖设备加数据服务"，客户粘性完全不一样。

6. 非标设备联网踩过的坑和绕过的弯路

6.1 网关选型贪便宜，结果在电柜里高温死机

早期做联网改造的时候，我选过一款便宜的网关，某宝上两百多块钱，说是工业级，实际工作温度范围只有0到50度。装在电柜里，夏天电柜内部温度能到55度，网关每天下午准时死机，重启之后又能用，第二天下午又死。

后来换了一款真正的工业网关，工作温度-40到75度，价格贵了三倍，但再也没出过高温死机的问题。这个教训让我明白：非标设备的电柜环境比办公室恶劣得多，网关的工业级参数不能只看宣传页，要看实际工作温度范围、防护等级、电源输入范围、抗振动指标。

还有一个细节：电柜里的变频器和伺服驱动器是强干扰源，网关的通信线如果和动力线走同一个线槽，通信会频繁出错。正确的做法是通信线单独走线槽，或者用屏蔽双绞线并单端接地。如果实在分不开，通信线要穿金属管或者用屏蔽层接地的屏蔽线。

6.2 协议对接时忽略了字节序，数据全是乱的

有一次对接一个国产PLC的Modbus寄存器，读上来的温度值一会儿是25.3，一会儿是65341.2，一会儿是负数。查了半天，发现是字节序搞错了。这个PLC的32位浮点数是低字在前，网关默认是高字在前，两个字节一交换，数据就完全乱了。

字节序这个问题在Modbus通信里特别常见。不同品牌的PLC对32位数据的存储顺序不一样，有的高字在前，有的低字在前。网关里一般都有字节序设置选项，配置的时候要查PLC的通信手册确认。如果手册里没写，可以用一个已知值去试，比如写入25.5，看读上来是什么，然后调整字节序设置直到读值正确。

缩放因子也是类似的问题。PLC里的温度值可能是实际温度的10倍或者100倍，网关里要设置对应的缩放因子。如果PLC程序里做了缩放，网关里就不用再缩放；如果PLC里是原始值，网关里就要缩放。这个要和PLC程序员确认清楚，不能想当然。

6.3 断网续传没配好，网络恢复后数据丢了

有一个项目在山区，4G信号不稳定，经常断网。网关支持断网续传，但我没配置好，网络恢复后只补传了最近一小时的数据，更早的数据丢了。客户后来要看一周前的历史曲线，发现那段时间的数据是空的。

断网续传的配置要注意几个点：本地存储容量要足够大，至少能存7到30天的数据；续传策略要设置成"按时间顺序补传"，不能只传最新的；续传时的上传频率要控制，不能网络一恢复就全速上传，把网络堵死；续传完成后要有确认机制，确保数据真的到了服务器。

后来我换了一款带32GB本地存储的网关，配置了30天数据缓存和顺序续传，再也没丢过数据。这个成本增加不多，但数据完整性完全不一样。

6.4 报警推送太频繁，运维人员直接屏蔽了通知

刚开始做报警推送的时候，我把所有报警都设成了立即推送。结果设备调试期间，各种报警频繁触发，运维人员的手机一天收几百条通知，最后直接把通知屏蔽了。真正重要的报警反而没人看。

后来我做了分级：调试期间的报警只记录不推送；运行期间的"警告"级报警只记录不推送，每天汇总一次；"故障"级报警立即推送，但同一个报警5分钟内只推一次，避免重复；"停机"级报警立即推送并电话通知。这样调整之后，运维人员不再屏蔽通知，重要报警的响应速度反而提高了。

还有一个经验：报警推送的内容要包含足够的信息，不能只推一个报警号。我一般会推：设备编号、设备位置、报警名称、报警时间、当前关键参数值、建议处理方式。这样运维人员不用打开电脑就能判断要不要立即处理。

7. 从单台联网到批量管理：非标设备商的能力升级

7.1 设备档案数字化，售后不再依赖老师傅的记忆

非标设备商最怕什么？最怕老师傅离职。老师傅脑子里装着几十台设备的配置参数、常见故障、处理方式，人一走，这些知识就没了。新来的工程师遇到问题，只能翻图纸、查手册、打电话问，效率低不说，还容易出错。

联网之后，每台设备的PLC程序版本、HMI组态版本、伺服参数、变频器参数、网关配置、报警历史、维修记录全部存在云端。新工程师接手的时候，打开设备档案就能看到这台设备的所有信息。遇到报警，先查历史记录，看之前有没有类似情况，当时是怎么处理的。

我们团队现在有一个规矩：每次远程处理完故障，都要在系统里写处理记录，包括故障现象、排查过程、根因、解决方案。这些记录积累起来，就是团队的共同知识库。新来的工程师跟着做几个月，就能掌握大部分常见故障的处理方法。

7.2 从被动维修到主动服务，客户续约率明显提升

传统非标设备商的售后模式是"客户打电话，我们才行动"。联网之后，我们可以做到"设备还没坏，我们就知道了"。

比如我们通过电流曲线监测到某台设备的电机电流缓慢上升，趋势持续了两周。系统自动生成预警工单，售后工程师联系客户，建议检查机械负载。客户检查后发现是皮带张紧度不够，调整之后电流恢复正常。如果等到电机过载报警再处理，可能已经烧了电机，停机时间至少半天。

这种主动服务让客户觉得设备商很专业、很负责。我们统计过，做了联网的设备，客户续约率比没做联网的设备高了将近20个百分点。客户觉得你不是卖完设备就不管了，而是一直在帮他盯着设备。

7.3 数据积累反哺研发，下一代设备设计更有依据

非标设备的设计往往依赖工程师的经验，但经验有时候是错的。比如某个机构的设计寿命是5年，但实际运行数据显示大部分设备在3年左右就出现磨损报警。研发部门看到这个数据，就会在下一代设计里加强这个机构，或者更换更耐磨的材料。

再比如，某款PLC在实验室测试时通信很稳定，但现场运行数据显示偶尔会丢包。研发部门分析后发现是现场变频器干扰导致的，下一代设备就会在通信线上增加磁环或者改用光纤通信。

这些数据驱动的改进，比拍脑袋决策靠谱得多。非标设备商做物联网联网，短期看是解决运维问题，长期看是在积累产品改进的数据基础。

8. 非标设备联网的几个现实问题，别被方案商忽悠了

8.1 联网不是万能药，机械问题还得靠机械解决

有些方案商把物联网吹得神乎其神，好像设备联网之后什么问题都能远程解决。实际情况是，物联网只能解决"信息不对称"的问题，不能解决物理问题。气缸漏气、导轨磨损、皮带断裂、传感器损坏，这些还是需要现场处理。

联网的价值在于：让你知道是什么问题、需不需要立即处理、带什么备件上门。它缩短的是排查时间和决策时间，不是维修时间本身。所以做联网方案的时候，不要承诺"远程解决所有问题"，要明确告诉客户联网能做什么、不能做什么。

8.2 数据安全不是小事，但也不用过度紧张

非标设备联网涉及数据上传，有些客户会担心数据安全。这个担心是合理的，但也不用过度紧张。非标设备的运行数据主要是设备状态和工艺参数，不涉及核心配方和商业机密。而且数据上传用的是加密通道，云端也有访问控制。

如果客户确实很在意数据安全，可以选本地部署的方案：网关把数据传到客户自己的服务器，设备商通过客户授权的通道访问。这样数据不出厂，客户放心，设备商也能远程运维。代价是需要客户提供服务器和网络环境，部署成本高一些。

8.3 联网改造要算经济账，不是所有设备都值得改

一台非标设备值不值得做联网改造，要看几个因素：设备的售后成本高不高、设备对客户生产的重要性大不大、设备的使用频率高不高、设备的位置远不远。

如果一台设备在客户隔壁，售后工程师骑电动车十分钟就到，而且设备一年也开不了几次，那联网改造的投入可能好几年都收不回来。如果一台设备在千里之外，客户24小时生产，停一小时损失几万块，那联网改造的投入可能一次上门就省回来了。

我一般建议客户先算一笔账：过去一年这台设备的售后成本是多少（包括差旅、人工、备件、停机损失），联网改造的成本是多少，联网之后预计能降低多少售后成本。如果一年内能收回投入，就值得做；如果三年都收不回来，就先放一放。

9. 写在最后：联网这件事，早做比晚做主动

非标设备行业正在经历一个变化：客户越来越年轻，他们对数据的要求越来越高；竞争越来越激烈，光靠价格和关系越来越难拿单；人工成本越来越高，靠人海战术做售后越来越不划算。

物联网联网不是万能药，但它是一个杠杆。它让设备商能用更少的人管更多的设备，让客户能更清楚地知道设备在干什么，让双方的合作从"一锤子买卖"变成"长期服务"。

我自己的体会是，联网改造最好的时机是设备还在厂内调试的时候。这时候电气工程师在场，PLC程序可以改，通信线可以加，网关可以慢慢配。等到设备拉到客户现场再想联网，成本至少翻倍，而且很多接口已经没法改了。

如果设备已经交付了，那就从最重要的一台开始改。不要想着一次把所有设备都联网，先选一台售后成本最高的设备做试点，跑通了再复制。试点的时候把协议对接、数据采集、报警推送、远程访问这些环节都走一遍，踩过的坑记下来，后面复制的时候就快了。

非标设备联网这件事，技术难度不大，难的是决心和耐心。决心是愿不愿意为未来投入，耐心是能不能把每一台设备的配置都做扎实。这两点做到了，联网的价值自然就出来了。