企业官网建设流程全解析

半夜接到现场电话说3号罐液位显示不对，而你人在两百公里外的办公室，这种场景干工控的兄弟应该都不陌生。过去我只能让现场人员拍照传回来，但拍的是不是当前画面、数据有没有滞后，心里完全没底。后来我把IR615路由器、InConnect平台和组态软件这套组合架起来，远程数据采集就变成了一件日常小事：只要现场设备通电联网，我坐在办公室就能像站在机柜旁一样看数据和操作。这篇文章完整记录一下这套方案的搭建过程，重点讲讲组态软件选型，以及我在FUXA里卡了很久的“多位号相加”到底怎么实现。

1. 这套远程数据采集方案，先搞清楚三个角色怎么分工

1.1 项目背景：出差率为什么降下来了

我手头这个项目是几个分散在不同厂区的泵站，每个站里有PLC、液位计和电表，原来靠人工去现场抄表，每周跑一遍，遇到设备报警还得临时出差。老板要的其实很简单：在办公室能实时看到每个站的液位、压力和电量，报警能第一时间弹出来。

市面上的方案五花八门，我最后选定的是“IR615路由器做边缘接入，InConnect平台做远程隧道，组态软件做数据展示”。这套组合最核心的价值在于，它把“现场设备如何上网”和“办公网如何访问现场设备”这两个问题彻底解耦了。现场不需要公网IP，办公室也不需要专线，两边都能用普通宽带，数据照样能拉回来。

很多朋友第一次接触时会觉得三个产品是三个独立的东西，实际上它们是一条完整的链路。IR615路由器负责在现场把PLC和仪表接入网络，InConnect平台负责建立一条安全加密的远程隧道，组态软件负责在这条隧道的基础上像访问本地设备一样去轮询数据并画成画面。少任何一个环节，远程数据采集都玩不转。

1.2 三个角色的具体职责

先明确分工，后面配置才有方向。

1.3 数据实际上是怎么流动的

现场仪表通过Modbus RTU接进IR615的RS485口，PLC通过以太网接进LAN口。IR615内部把这些数据统一封装成Modbus TCP，然后通过4G网络向外发起连接到InConnect平台。办公室这边，电脑上运行InConnect的远程访问客户端，建立一条加密隧道，电脑上会多出一块虚拟网卡，IP地址和现场PLC处在同一个逻辑网段。这时候组态软件里填的PLC地址，就是那个虚拟网段的IP地址，读写操作跟在局域网里一模一样。

这条链路里最容易被忽视的一点是：数据轮询是由办公室那一侧的组态软件主动发起的，现场侧的IR615只需要保证网络在线即可。也就是说，现场路由器不需要做端口映射，不需要暴露任何业务端口到公网，这比传统“公网IP+端口映射”的方式安全得多。

2. IR615路由器配InConnect平台，远程通道这样一步步打通

2.1 现场侧路由器的接线与初始化

IR615这种工业路由器拿到手，先别急着上电，把几个硬件点理清楚。电源是9到36V直流输入，现场用24V开关电源供电就好，接线端子标得很清楚。SIM卡槽在机身侧面，把物联网卡插到位，注意有些卡需要剪卡或者使用卡套。天线接口是SMA的，4G天线必须拧紧，很多信号差的问题其实都是天线没拧到位导致的。

网口方面，IR615一般带两个以太网口，一个做WAN上行（接现场宽带），另一个做LAN（接PLC）。如果现场没有宽带，直接用4G拨号作为上行，WAN口可以空着或者也接进去做有线备份。我习惯把PLC接在LAN口，把路由器管理IP设为和PLC同一个网段，这样后面调试方便。

初始化配置通过网线连接电脑和路由器的LAN口，浏览器打开管理页面。需要注意设备默认IP可能和现场网络冲突，电脑先改成同网段的静态IP再访问。进去之后第一件事是设置4G拨号参数，APN一般由SIM卡运营商提供，很多物联网卡还需要配置专用的APN和用户名密码，这一步可以向卡商要参数。

2.2 InConnect平台上绑定设备

InConnect平台是这套方案里打通远程访问的关键。先说原理：现场IR615会持续主动向InConnect云平台发起出站连接，平台记录这个设备的在线状态和通道信息。办公室电脑也装一个InConnect远程访问客户端，登录同一个平台账号后，就可以在平台里选择现场设备并建立一条加密隧道。这样现场设备不需要任何公网IP，不需要路由器做端口映射，所有连接都是出方向的，防火墙基本拦不住。

平台操作的流程大致分三步。第一步注册InConnect账号，在平台里添加设备，填IR615的序列号或IMEI号。设备ID在路由器机身铭牌上有，也可以从路由器Web管理页面的状态栏查到。绑定后平台会显示设备在线状态，如果显示离线，优先检查SIM卡是否正常拨号、路由器的平台连接选项是否打开。

第二步是创建远程访问通道。在InConnect平台的项目或设备详情里，可以给这台设备分配一个虚拟网段或者远程节点ID。我的做法是把所有现场PLC规划成统一的192.168.100.x网段，比如泵站1的PLC是192.168.100.11，泵站2的PLC是192.168.100.12，这样组态软件里配置轮询地址时非常直观，不会搞错站。虚拟网段要避开办公室局域网段，否则路由冲突。

第三步是办公室电脑上安装并登录InConnect客户端，确认虚拟网卡已启用。用ping命令测试远程PLC地址的连通性，能通就说明整条隧道已经建立起来了。这里有个小技巧：ping通后，用Modbus Poll或类似工具直接读一下PLC的寄存器，能读到就说明链路没问题，可以开始配置组态软件了。

2.3 远程侧连接与日常使用细节

远程通道建好以后，办公室电脑上就相当于多了一张“虚拟网卡”，它的IP是平台分配的，和现场PLC在一个虚拟网段里。组态软件里的设备地址，填的不是现场真实的IP，而是这个虚拟网段里PLC对应的地址。如果现场PLC配置的是192.168.100.11，那组态软件里也要填192.168.100.11，因为虚拟网卡已经把网络“延伸”到了现场。

这里有一个很容易踩的坑：现场PLC的IP如果和办公室局域网冲突，比如办公室也是192.168.0.x、现场也是192.168.0.x，那虚拟网卡路由表的优先级会导致数据根本不通。我建议在做这套方案时，把所有现场设备的IP规划统一用172.20.x.x或者10.10.x.x这种不常用的网段，从根上避免冲突。如果现场设备IP已经固定改不了，那就必须在办公室电脑的路由表里添加一条静态路由，把所有到虚拟网段的流量都指向InConnect虚拟网卡。

2.4 路由器选型的几个注意点

选工业路由器不能只看价格，几个关键参数要盯住：一是支持的网络制式，要覆盖现场运营商的频段；二是串口数量，如果现场既有Modbus RTU设备又有以太网设备，至少要选带1路RS485的型号；三是电源输入范围，现场电压波动大的话，宽压很重要；四是有没有看门狗功能，工业路由器长期通电运行，偶尔会死机，有硬件看门狗的话会自动重启恢复，省心不少。

另外一个容易被忽略的是天线和SIM卡。很多物联网卡默认只开通了专用APN，平台域名或服务器地址必须加白名单，否则隧道建不起来。遇到路由器显示4G已连接但InConnect平台不显示在线的情况，九成是APN参数不对或者平台域名被卡商的防火墙拦了。直接联系SIM卡商把InConnect的服务器域名加进白名单即可。

3. 组态软件选型：为什么我推荐用FUXA做远程数据展示

3.1 组态软件的几种选择，各有什么优劣

隧道打通之后，组态软件就是最后一步。市面上的选项大致分三类：传统商业组态软件、开源Web组态、物联网云平台。

传统商业组态软件如WinCC、组态王、力控，功能确实强，做大型SCADA项目很合适，但授权费用不低，而且一台电脑一套授权，远程访问还得额外装客户端或配置Web发布，对于中小型项目来说性价比一般。

物联网云平台如阿里云IoT、ThingsBoard，好处是设备接入后有完整的云端生态，手机App也能看。但数据都要先上云，再从云拉到本地展示，链路多了两层，实时性和可靠性都会打折扣。而且云平台是按点位和设备数量收费的，点位多了费用也上得去。

开源Web组态里FUXA是比较合适的选择。它是基于Node.js开发的，浏览器直接访问，本地部署免费，支持Modbus TCP/RTU、OPC UA、MQTT等常见工业协议，自带画面组态、趋势曲线、报警管理，该有的都有。我把三个方案做了一张对比表，方便各位按项目情况判断。

FUXA对我的场景还有一个好处：它跑在一台普通PC或小服务器上，办公室内网打开浏览器就能看，不需要装客户端，出差的时候也可以通过InConnect隧道访问到组态软件的Web服务。这一点在实际使用中太方便了，领导要看看数据，发个链接过去就行。

3.2 FUXA的部署方式

FUXA部署不复杂，有Node.js环境就可以跑。我推荐用Docker方式，封装好之后迁移方便，重启也快。

docker run -d --name fuxa --restart=always \ -p 1881:1881 \ -v fuxa-data:/home/pi/fuxa \ frangoteam/fuxa

跑起来之后，浏览器访问http://服务器IP:1881，默认端口是1881。首次进入会要求创建管理员账号，然后就可以新建项目了。没有Docker环境的也可以直接用Node.js跑，GitHub上代码拉下来，npm install之后npm start，效果一样，只是升级维护不如Docker省事。

FUXA项目结构里几个核心模块要理解清楚：Tags是变量标签，也就是数据点位；Dashboard是画面组态；Logic是逻辑处理，可以做简单的计算或联动；Alarms是报警管理；Settings里配置设备驱动连接。远程数据采集项目的大部分操作都在Tags和Dashboard两个模块里进行。

3.3 在FUXA里建立Modbus TCP设备连接

FUXA里添加设备的位置在Project Settings或Devices管理页。驱动类型选择Modbus TCP，然后填写远程PLC的IP地址和端口，默认Modbus端口是502。这里的IP地址填的必须是InConnect虚拟网段里PLC的地址，比如192.168.100.11，而不是隧道的什么中转地址。

配置完设备连接，紧接着就是添加变量Tag。每个Tag对应一个寄存器地址，需要根据PLC的数据表来定义。以Modbus保持寄存器为例，功能码是03，地址范围从0开始，但很多PLC的说明书上写的是40001开始，这里有个常见的偏移坑：说明书上的40001对应软件配置里的0，40002对应1，以此类推。地址填错一位，读出来的数据就是隔壁寄存器里的东西，画面上的数值完全对不上。

数据类型也要注意，寄存器默认是16位，如果PLC里存的是32位浮点，那FUXA里要将Tag类型设成Float并指定字节序。很多PLC里Float是大端模式，FUXA默认可能按小端解析，填错了数值会变成一个巨大且毫无意义的天文数字。我的习惯是先用Modbus Poll把每个寄存器的原始值读出来核对一遍，再在FUXA里建Tag，能省下后面排查数据的半天时间。

3.4 FUXA画面组态的基本流程

Tags建好之后，画面组态就比较直观了。新建一个Dashboard，从左侧组件库里拖入控件，绑定对应的Tag，保存后就能看到实时数据。常用的组件包括数值显示、仪表盘、指示灯、趋势曲线和报警列表。我这套泵站项目里，每站做了三个画面：总览画面、设备详情画面、历史趋势画面。

总览画面放每个泵站的液位和压力大数，用旋钮表和数字显示。设备详情画面放PLC的I/O状态、水泵运行反馈和故障报警。历史趋势画面绑定流量计和液位Tag，设置好时间范围，可以查看过去24小时的变化曲线。FUXA的趋势组件支持多种采样方式，历史数据存在本地SQLite里，查询速度还可以。

4. FUXA组态软件怎么实现多位号相加，三种落地方式实测对比

4.1 为什么“多位号相加”会让很多人卡住

FUXA本身没有一个直接的“表达式计算器”组件，Dashboard里的数值显示控件只支持绑定单个Tag，不支持类似Tag1 + Tag2这种公式语法。很多第一次用FUXA的人会想在文本控件里直接写表达式，发现不行，然后就开始怀疑是不是软件不行。

实际项目中“多位号相加”的需求非常普遍。比如三个泵的电流加起来看总负荷，两个罐的液位总和作为库存量，或者多路电表的功率累加成一个总功率。这个需求本质上是数据的聚合计算，需要的是“多输入、单输出”的处理能力，而FUXA的基本组件模型是“单输入、单输出”，所以直接做不了。

解决思路有三条路，而我实际测下来这三条路的适用场景和优缺点差别很大。先说结论：如果现场有PLC，就让PLC做加法；如果不方便改PLC程序，就引入Node-RED做中间聚合层；如果只是临时看看数且数据量不大，可以用FUXA自带的Logic模块凑合一下。

4.2 方案A：在PLC侧算好，组态软件只读结果

这是最简单可靠的方式。现在的PLC无论是西门子、三菱还是国产的，都有加减指令或者内部浮点运算功能。在PLC程序里把三个电机电流读上来做个ADD指令，存到一个新的寄存器里，组态软件直接读这个寄存器，所有数据都在源头算好了。

这样做的好处是实时性最好，因为加法在PLC扫描周期内就完成了，不需要上位机干预；上位机哪怕组态软件暂时卡顿，最终读取的结果也是准确的。坏处是需要改PLC程序，如果现场是第三方设备、程序加密或者没有源码，这条路就走不通。

另外一个隐蔽的问题是PLC程序里的数据类型。如果PLC算完的结果存的是32位浮点，组态软件侧也要按浮点来读。有些老工程师习惯把所有数据都转成整数或双整数，这时候小数部分就被砍掉了，显示出来的总功率和实际值差很多。我的经验是，能传浮点就传浮点，实在不行传放大十倍的整型，组态软件侧再除以十。

4.3 方案B：Node-RED做数据聚合，MQTT喂给FUXA

PLC程序不方便改、但又想做多位号相加，我最推荐引入Node-RED。Node-RED本身就是做流式数据处理的开源工具，它可以从Modbus把各个位号的原始值读出来，在function节点里做加法计算，算完之后通过MQTT协议推给FUXA。FUXA本身就支持MQTT驱动，订阅对应的topic就能拿到算好的总和。

链路结构大概是这样的：

现场仪表/PLC -> Modbus TCP/RTU -> IR615 -> InConnect隧道 -> 办公室Node-RED -> MQTT Broker -> FUXA

Node-RED这边需要安装两个贡献包：node-red-contrib-modbus和node-red-contrib-mqtt-broker。Modbus节点负责从远程PLC读取原始数据，MQTT节点负责把计算结果发布出去。加法逻辑在function节点里写JavaScript，几行代码就够了。以下是我实际在用的一段示例，逻辑是先把三个测量值的topic数据存到上下文，任一更新后重新计算总和并发送：

var topic = msg.topic; var sensor = context.get('sensor') || {}; sensor[topic] = Number(msg.payload); context.set('sensor', sensor); var v1 = sensor['power1']; var v2 = sensor['power2']; var v3 = sensor['power3']; if (v1 !== undefined && v2 !== undefined && v3 !== undefined) { msg.payload = v1 + v2 + v3; msg.topic = 'station1/power/total'; node.status({text: '总和=' + msg.payload}); return msg; } return null;

这个方案的优点是不需要改现场设备，也不依赖FUXA内部有没有计算功能，只要FUXA能收MQTT就行。缺点是链路里多了一个中间件，就多了一个要维护的服务。但对我这种要接大量不同型号设备的项目来说，Node-RED这个中间聚合层太值了，它把繁琐的协议转换和数据清洗都集中处理了，FUXA只需要专注展示。我在Node-RED里同时聚合了五个泵站的数据，每个泵站都有一组功率累加和液位累加，跑得很顺畅。

MQTT Broker我是在办公室服务器上用Docker直接跑了一个Eclipse Mosquitto，配置很简单。FUXA里添加设备时驱动选MQTT，然后配置Broker地址、端口和订阅主题。这里有一个注意点：FUXA的MQTT订阅topic必须和Node-RED发布端的topic完全一致，包括层级分隔符。有的Topic里带斜杠，订阅时写错一个字母就收不到数据。

4.4 方案C：用FUXA自带的Logic模块做加法

如果不想额外装Node-RED，FUXA的Logic模块也能做简单的加法运算。在FUXA里新建逻辑标签，把需要相加的Tag作为输入，添加一个“Math Operation”节点，选择加法，输出到一个计算后的Tag，然后Dashboard绑定这个计算Tag显示。

这个方案在逻辑上可行，但实际用下来有几个限制。第一，FUXA的Logic运算机制是触发式的，只有当输入变量变化时才会触发计算，如果输入值长期不变，输出就不会更新，对于需要恒定显示的场景问题不大。第二，Logic节点的调试能力比较弱，算出来结果不对时，排查链路没有Node-RED里的断点方便。第三，多位号加权相加这种稍微复杂的运算，在Logic里要搭好几个节点，维护起来并不直观。

所以我的判断是，Logic模块适合做一次性的临时计算或者演示场景，真正进入长期运行的项目，我建议用方案A或方案B。我实际项目里这两种都用：有新项目能改PLC程序时用方案A，老项目改造或者设备类型杂时用方案B。

4.5 三种方案的选型建议

还有一个思路是直接在FUXA的Tag配置里把Modbus地址指向一些内部虚拟寄存器，其实还是要外部算好才能写进来。所以不用纠结FUXA为什么不能像Excel表格一样写公式，它定位是SCADA的展示层，数据计算交给更擅长做的工具去处理，整个系统反而更可靠。

5. 远程数据采集现场最常见的5个坑和排查方法

5.1 隧道通了但组态软件读不到数据

这个坑我遇到不下三次。拨号正常、InConnect平台显示设备在线、命令行ping虚拟网卡里的PLC地址也能通，但FUXA里就是读不到数。最后定位下来是FUXA的Modbus TCP驱动配置里，寄存器地址起始位没搞对。

很多PLC的Modbus地址表是1基地址，而驱动内部从0开始算。你在FUXA里填地址0时，实际访问的是PLC数据表里的地址1，也就是说明书上的40001的0偏移，这个对不上就会串位。排查方法很简单，先用Modbus Poll按地址0、1、2逐个读，看哪个地址读出来的值是现场设备的第一个变量，然后根据这个偏差来校正FUXA里的地址配置。这类问题一旦确定是偏移问题，基本5分钟就能解决。

5.2 数据偶尔刷新慢，过一会儿又不刷新了

排查这种问题，先看InConnect平台的隧道连接状态，再看FUXA驱动的轮询周期。Modbus TCP一个连接上可以连续读取多个地址，FUXA默认会对每个Tag单独发送请求。如果Tag建了几十个，每个Tag相隔100毫秒轮询，一圈下来要好几秒，画面看起来就像卡了一样。

解决办法是把连续地址的Tag合并成批量读取。Modbus协议本身就支持一条请求读多个连续寄存器，FUXA驱动也支持按块读取。我把每个泵站的数据点按地址段分成几组，一组一组读，组间间隔500毫秒，响应速度比原来快了几倍。不要贪快把间隔调到100毫秒以下，很多仪表或老款PLC对高频轮询会直接无响应，到时候反而更麻烦。

5.3 相加算出来的数值是天文数字

这个坑多数是数据类型和字节序不匹配导致的。PLC里存的是32位浮点数，FUXA组态软件里按16位整数来读，那读出来的两个寄存器会被拆成两个毫无意义的整数，Node-RED里相加自然是天文数字。还有的PLC支持大端字节序，而FUXA或Node-RED默认按小端解析，字节顺序反了整个数就错乱。

排查方法有三步：第一步，确认PLC数据表里这个变量的数据类型，到底是16位整数、32位整数还是32位浮点；第二步，确认FUXA或Node-RED里设置的变量类型和它一致；第三步，如果一致还是不对，就检查字节序。FUXA的Modbus设备属性里一般都有字节序选择，Node-RED的Modbus节点也有对应参数，挨个试一遍，数值合理的就是正确的。

5.4 InConnect隧道突然断开或连不上

隧道断开通常有两个原因。一个是现场网络不稳定，4G信号弱或者SIM卡欠费断网，路由器会自动重拨，但隧道重新建立需要一点时间。另一个是办公室客户端所在电脑休眠或网络切换，隧道也会断。先登录InConnect平台看两边的在线状态，一边不在线就单独处理那边。

预防措施方面，我给现场IR615配了双SIM卡功能，一张主卡一张备用卡，主卡断线会自动切换到备用卡。路由器本身也启用了看门狗，检测到网络异常会自动重启模块。办公室客户端那台电脑我设置了永不睡眠，并把InConnect客户端设为开机自启动。这套组合下来，远程通道的可靠性提升非常明显。

5.5 数据能读到，但偶尔会出现明显错误值

这种情况通常是现场干扰或者通信抖动导致的。Modbus协议本身没有很强的校验，误码时会读到一些异常值。在PLC侧可以做滤波或死区判断，在Node-RED侧可以加一个简单的限值逻辑，数据超出合理范围就直接丢弃。我当时在Node-RED里给每个液位变量加了范围检查，超过上限或低于下限的值一律不参与求和，并且记录一条告警日志，画面上就不会突然跳出一个吓人的数字了。数据采集这种事，宁可少显示一条，也不能显示一条错的。

6. 这套系统跑了一段时间，说几点实际感受

我自己实际项目里，这套IR615加InConnect加FUXA的链路已经稳定运行了大半年，最大的感受是调试效率明显提升。以前现场设备改个参数，我得专门跑一趟或者让现场电工远程配合，现在直接打开FUXA画面，点两下就把事情办了。领导要求看数据时，浏览器里打开IP地址就行，不用装任何东西。

如果让我重新搭建一遍，我会在一开始就把所有泵站的IP规划好，统一用不冲突的虚拟网段，同时在一开始就引入Node-RED做数据层，而不是等后面要加法计算了才想起来加。FUXA负责画面和报警，Node-RED负责逻辑处理，这个分工一开始就明确的话，后面的坑至少能少踩一半。

最后再分享一个小技巧：在InConnect平台里把所有现场站点都打上标签和备注，同时把FUXA的画面URL通过隧道发布出来，出差时手机连着办公网的远程通道打开浏览器也能看数据。我上次在外地出差，就是用这个方法在酒店电脑上完整看到了泵站的实时运行状况，那种感觉就是，这套系统没白搭。