前阵子帮客户做一套设备远程监控的评估方案对方开口就问能不能把车间里的控制器数据直接放到浏览器上让几个经理同时打开页面就能看不用装一堆客户端我第一反应是想推荐商业组态软件但报价单递过去之后甲方项目负责人直接摇头。于是我开始认真翻开源社区最后把目光锁定在 FUXA 这套开源的 Web 可视化组态软件上。折腾了一周把一台 Linux 服务器、若干台 Modbus 从站和一个大屏页面完整打通了。这篇就把这套软件是什么、能干什么、怎么搭、有哪些坑一次讲透。FUXA 本质是一套基于 Web 的 SCADA/HMI 组态平台。它把传统组态软件里的设备通讯、数据采集、画面编辑、历史存储、告警事件全部搬到了浏览器和服务端后端用 Node.js 处理采集与逻辑前端直接在线拖拽设计画面最终给用户看到的也是浏览器里的一套实时监控界面。对中小规模的工业现场、设备远程运维、实验室演示、高校课题来说它基本覆盖了「可视化监控」的绝大部分需求。1. 为什么还要折腾一套Web组态软件传统方案的痛点与FUXA的位置1.1 组态软件到底干了什么活组态软件这个行当干的事说穿了就是把两样东西打包起来底层各设备的通讯协议和上层的人机交互界面。现场有几十台仪表、PLC、传感器它们各自说话的协议不一样组态软件负责把这些协议统一收拢转成一组干净的数据点然后工程师在画图板上拖几个管道、阀门、仪表盘把这些数据点填进去画面就「活」了。过去做一套集中监控基本绕不开商业组态平台。边界说法就是比较成熟的商业平台确实功能全、生态好但问题也不少。最头痛的是费用很多商业组态按点位收费一个项目几百上千个点授权费就上去了后面每加一台设备都得再算钱。部署也重工程做完了发到现场往往还要装运行时、装驱动、配授权运维人员稍微操作错一步就起不来。至于跨平台能力基本被操作系统绑死想放到 Linux 服务器上长跑或者让领导在手机上快速瞄一眼都得额外做一堆适配。1.2 传统组态软件的三个尴尬我在实际项目里遇到的尴尬基本可以归纳成三类。第一是远程访问难。传统组态软件的核心交互在桌面客户端要做远程访问要么上远程桌面要么再套一层网页发布模块。前者体验差后者往往要加钱买模块而且配置链路很长。客户要的其实很简单一个链接浏览器打开实时数据看得到。第二是二次开发门槛高。商业组态大多有自己的脚本语言和组件体系学起来有一套自己的逻辑。遇到特殊需求比如对接内部 API、把数据推到企业数据库厂商支持的脚本接口够不够用就完全看人品。实在不行想改底层源码根本拿不到只能打电话提需求等版本更新。第三是项目交付和修改的节奏脱节。画面改一个阀门颜色、加一个趋势曲线在组态软件里做完还要导出、发布浏览器端才会更新。客户在现场看效果提意见改一版再导出再发布循环几轮大家都很累。1.3 FUXA到底是什么FUXA 走的路子完全不同。它是开源的源代码挂在社区里想改哪块改哪块不存在授权点数的说法。技术栈上后端是 Node.js用 Express 提供 Web 服务用 Socket.IO 做实时推送前端是一套基于浏览器画布的可视化编辑器也是最终运行时的载体。整套系统跑起来就一个 Node.js 进程它负责设备通讯采集、历史数据落盘、告警判断、Web 服务分发。客户端什么插件都不用装Chrome 或者 Edge 打开页面就能看到画面并且支持多人同时在线查看——这一点在传统组态里往往要折腾很久。数据存储层面支持本地文件、内嵌数据库和外部数据库几种模式小项目开箱即用大一点的数据量也能撑住。它适合谁来用我认为主要是这三类人自动化、物联网方向的工程师需要快速给客户交付一套监控 Demo设备厂商给自己的产品配一个远程运维看板高校或实验室用低成本搭一套数据采集与可视化实验平台。当然边界也得说清楚FUXA 定位是轻量级 SCADA/HMI中小规模项目很合适要做大型集散控制、高可靠性冗余、复杂调度策略目前它还不是这个量级。别拿它去直接闭环控制关键工艺这是原则问题。2. 功能地图FUXA能覆盖哪些监控需求2.1 跟传统组态平台放在一起看与其逐个列功能菜单不如把 FUXA 和商业组态软件放在一张表里对比。这样选型的时候心里更有底。对比项传统商业组态软件FUXA部署方式开发端安装软件、现场端安装运行时服务器一个 Node 进程浏览器访问授权费用按点位/按套收费远期成本高开源免费跨平台多绑 Windows部分支持 Linux服务端跨平台客户端纯浏览器远程访问需额外模块或远程桌面天然 Web 化手机也能开二次开发闭源脚本接口有限开源可改源码可写脚本图形能力图库丰富工业组件多内置基础控件支持 SVG 导入数据接入驱动库庞大覆盖主流通讯长尾驱动需自研适合规模大中小均可偏大中项目中小项目最佳这个表不是要论证 FUXA 能取代传统组态而是说明在不同场景下两者各有阵地。如果是上百台设备的大型工厂集控商业组态成熟可靠、驱动丰富、技术支撑到位该花钱就花钱。但如果项目规模在几台到几十台设备点数不过千又要快速上线、频繁改版FUXA 的性价比就非常突出。2.2 数据采集这块能接什么FUXA 的数据采集模块是它最核心的部分直接决定这软件能不能进入你的项目。目前支持的主流协议包括Modbus TCP 和 Modbus RTU通过串口连接时走 RTUOPC UA用于对接支持 OPC UA 的 PLC、仪表或上层软件MQTT物联网场景最常见设备数据通过消息服务器转发BACnet/IP楼宇自控领域常用的协议Siemens S7 系列通讯针对西门子 PLC 的直连场景。实际项目里Modbus TCP 是最省事的。几乎所有 PLC、仪表、网关都支持 Modbus TCP甚至一块树莓派都能跑一个 Modbus 从站模拟器来测试。你在 FUXA 里配好设备的 IP 和端口把寄存器地址映射成标签数据就开始源源不断地往里灌。OPC UA 适合那些数据已经汇到上层的数据环境比如工厂里的多套设备统一通过 OPC UA 服务器对外提供数据FUXA 直接作为客户端去读就行。2.3 画面、脚本、告警、历史这些上层功能数据采上来了接下来就是组态软件发挥价值的地方。画面编辑方面FUXA 提供在线拖拽式编辑器按钮、开关、指示灯、实时数值显示、仪表盘、趋势图、报警列表、下拉框、表格组件这些基本控件都有。更重要的是它支持直接导 SVG 图元复杂设备外形、工艺管线可以用设计软件画好再导入工业现场那套「画得好看」的诉求基本能满足。脚本和联动逻辑是 FUXA 相比某些轻量级物联网平台的加分项。你可以在画面控件的事件里写 JavaScript 代码比如点了某个按钮切换页面也可以在后台写定时脚本每小时把累计产量归档一次。我们做项目的时候常用它做简单的数据处理把原始寄存器值乘一个系数换算成工程单位或者判断设备状态字里的某个位是否为 1再决定指示灯亮什么颜色。告警和历史是监控系统的标配能力。标签可以设置上下限和死区越限后触发告警事件告警列表会把时间、位号、描述显示出来历史数据方面勾选了存储的标签会按设定周期写入存储在趋势控件里选中位号就能拉出曲线。用户权限分了多个角色可以做到只看画面的只读账号和能改配置的工程师账号分离。3. 半小时跑起来安装部署与工程创建3.1 环境准备和启动FUXA 对服务器要求不高我建议给它准备一台能跑 Node.js 的 Linux 机器就行1 核 2G 跑小项目完全没问题。Windows 上也能开发调试但生产环境我更推荐 Linux长期跑更稳。第一步是装 Node.js。不一定非要用最新版建议选 LTS 版本装好版本太新或者太旧都可能遇到依赖编译的坑。装完确认一下node -v npm -v第二步把代码拉下来。开源项目直接在社区仓库里克隆或者下载压缩包都行git clone 仓库地址 cd 项目目录 npm installnpm install 这一步耐心等如果网络慢可以给 npm 配上国内镜像加速。装完直接启动npm start看到控制台输出启动成功的日志后浏览器打开启动日志里提示的地址和端口。第一次访问会要求用初始管理员账号登录登录成功后第一件事就是改掉默认密码这个习惯要养成。3.2 数据存储方案的取舍FUXA 支持几种存储方式装的时候没想清楚后面会后悔。我的建议是纯测试、体验用默认的本地文件存储模式就够了数据全在一个数据目录里导出备份很方便项目要跑几个月、点位又多此时把历史数据落在数据库里更稳避免文件越滚越大。有 MongoDB 基础条件的可以用外部数据库没有额外依赖就选用内嵌数据库方案对中小项目最省心。实际项目中我倾向内嵌式数据库因为少一个外部服务的依赖部署和运维难度都低。历史数据量如果大到单文件承受不住再考虑外部数据库。存储方案确定后后续工程里就别频繁切换了否则历史曲线会断档。我们吃过一次亏项目上线的第一周为了测试切换存储模式结果头两天积累的趋势曲线全丢。对甲方来说历史数据是凭证丢了很难解释。3.3 新建工程和画面登录之后进到编辑器主界面整个操作逻辑跟常见组态软件类似。左侧是功能面板中间是画布右侧是属性栏。我的建议是先创建一个「总览」画面把整体布局想好左侧放设备状态区中间放工艺流程或设备分布图右侧放实时数据卡底部放告警列表。FUXA 的工程管理和习惯的组态软件不太一样画面文件、图元文件、脚本文件都要分门别类整理命名规则从第一天就定好。否则等到画面上百个图元的时候找东西会找到怀疑人生。画面布局确定后先别急着精雕细琢。第一步是走通「数据链路」建设备、建标签、往画面上拉一个数值控件、绑定标签、保存、预览。这条链路通了整个软件的核心用法就算掌握了。我用一个章节专门讲这条链路因为它太容易被忽视。4. 让画面动起来从设备到控件的数据链路4.1 创建设备和标签先建立数据源头FUXA 里的「设备」就是数据源头。进入设备管理页点新增设备协议下拉框就是第一节提到的那几种。以最常见的 Modbus TCP 为例需要填从站的 IP 地址、端口、从站号以及字节序设置。字节序这里非常容易踩坑我在现场就遇到过「数据看起来跳得离谱」的情况。Modbus 的寄存器本质是 16 位整数两个相邻寄存器才能拼成一个 32 位浮点数拼的时候高位在前还是低位在前各家设备实现并不统一。FUXA 的配置项里有多少种字节序组合需要试验得出。好的做法是配一个已知的固定值进去逐个切换字节序看哪个读数对了再批量应用。设备建好之后下一步就是建「标签」。标签也叫数据点相当于组态软件里的变量。每个标签对应设备的一个可读或可写的量需要定义它的名称、数据类型、地址或数据源。数据类型要严格和实际变量匹配常见有开关量、有符号整型、无符号整型、单精度浮点等。以 Modbus TCP 设备为例读一个保持寄存器时地址填法和设备手册对得上就行然后定义好标签名称比如Tank_Level。建标签的时候还要考虑轮询周期某个点的刷新频率设为多久。全部标签统一设 100ms 是很傻的做法既浪费带宽又拖慢整体后面第五章专门讲怎么设置合理。4.2 控件绑定标签这是最核心一步建好标签后进入画面编辑。在控件库里拖一个「数值显示」或者「仪表盘」到画布上然后在右侧属性面板里找到数据源绑定相关的配置把刚刚建的Tank_Level标签挂上去。这里要说清楚 FUXA 的一个设计控件显示内容是靠「属性绑定」完成的。每个控件有一堆属性比如背景颜色、文本内容、可见性、角度、填充进度等每个属性都可以绑定一个标签或者一个表达式。表达式的意思就是不只是简单显示标签值还可以写一段文本或公式控制属性在特定条件下变化。举个例子指示灯控件有一个「颜色」属性我想让它根据设备运行状态变化状态是 1 显示绿色是 0 显示灰色。可以直接在颜色属性里写一个条件表达式判断绑定标签的值来决定返回什么颜色。这样一来画面上所有动态效果本质上就是一系列控件属性对标签值的映射关系。这步是 FUXA 区别于普通图表工具的精髓不是画完图再贴数据而是画布上的每一个图形和属性都直接和数据源建立了活链接。保存画面后切换到运行预览模式数据变化立刻反映在控件上。4.3 最小可复现的完整示例我建议每个初学 FUXA 的人花二十分钟做一个最小示例。步骤如下在本机跑一个 Modbus 从站模拟器随便什么工具都行创建一个保持寄存器内容定义一个不断变化的值在 FUXA 里新建一个 Modbus TCP 设备指向模拟器的 IP 和端口为该设备建两个标签一个是开关量一个是整型数值新建画面拖两个开关量指示灯和一个数值仪表盘分别把控件的颜色/数值属性绑定到标签进运行模式看看控件有没有跟着模拟器的数据变化。如果这个最小示例走通了FUXA 的数据链路机制你就掌握了八成。后面无论接多少设备多少个点核心都是这一步的放大版。第一阶段整个项目调试时我们也是先用一个模拟从站验证完了链路再切换成现场真实设备大大减少了联调时的排障压力。4.4 用脚本做进阶联动标签绑定解决的是「数据显示」脚本解决的是「业务联动」。FUXA 支持在控件事件和服务端逻辑里写 JavaScript。现场最典型的需求场景是现场操作员按了一个启动按钮要经过确认提示、校验设备状态、发送写指令、再更新画面按钮颜色。这些用纯属性绑定做不完整但脚本就很顺手。按钮点击事件里判断设备是否处于远程模式不是就弹窗提示是就执行写寄存器操作成功后把按钮文本改为「运行中」。脚本功能给 FUXA 带来了非常强的扩展性对接内部 HTTP API、把报警信息推送给我们自己的消息通道、定时抓取外部数据再写入标签都能实现。开源项目的脚本接口就是一张白纸能画什么取决于你自己的想象力。5. 真实项目的选型与调优实践5.1 一个模拟改造项目的配置思路这边说一个之前做过的模拟改造项目。需求是给一套小型设备环境做远程监控甲方要能看到设备启停状态、主要工艺参数、历史趋势和告警信息部署位置就是一台办公室里的 Linux 小主机。整个项目的结构是这样的数据源一台 OPC UA 服务器整合了五台 Modbus 仪表的数据采集端FUXA 部署在 Linux 上通过 OPC UA 客户端接入画面端三台办公电脑用浏览器访问其中经理的账号设置为只读外网访问通过反向代理提供 HTTPS 接入方便在外面打开手机看状态。实施第一步仍然是分模块验证先把 OPC UA 数据源接入成功标签建好可以看到实时值再画主页面最后才是做告警和趋势。整个过程用了一周大头反而花在画面上——甲方对视觉呈现的要求不比功能低。这个项目验证了 FUXA 的中小项目承载力100 多个点位同时刷新多台浏览器并发访问稳定性完全 OK。服务器资源占用也比较低日常 CPU 保持在个位数百分比。5.2 轮询与性能优化别一上来就全 100ms数据刷新频率是整个系统性能的命门。不少第一次用的人习惯把所有点位的刷新周期都设为 100ms 或者 200ms结果设备通讯负载陡增画面反而卡顿。因为 FUXA 的采集是服务器主动去读设备每个点位一个周期点位一多大量频繁请求会挤爆通讯通道。我的建议是分类设置开关量、设备运行状态刷新周期设 1 秒反映按钮状态变化足够快了模拟量、温度压力液位等过程量设 2~5 秒工业过程本来就不是毫秒级突变的累积量、电表读数10~30 秒甚至更久这类数据变化缓慢读太勤没有意义。实时性和负载是权衡关系。客户问你为什么页面数据不是每毫秒更新你跟他解释清楚工业现场的物理本质他会理解。反倒是一股脑全设成快刷新现场通讯一不稳定画面数据偶尔跳一下客户反而觉得系统不可靠。画面上图元数量也要控制。趋势图、SVG 复杂图形本身就占渲染资源一个画面塞几百个复杂图元低配电脑浏览器会明显卡顿。合理做法是一个监控主题一页每页重点图元数量控制在几十个量级次级信息放到跳转页去。5.3 远程访问与安全部署FUXA 服务默认监听的端口不要直接暴露到公网这是底线。生产环境的推荐做法是让它跑在内网只通过反向代理对外提供 HTTPS 服务同时把 WebSocket 升级也代理好因为 FUXA 实时推送依赖 WebSocket。对外访问链路可以这样规划内网设备 → 交换机 → FUXA 服务器外网手机/电脑 → HTTPS 反向代理 → FUXA 服务。用户权限上FUXA 内置的角色体系要启用起来。给甲方领导配只读账号只能看画面和趋势给现场工程师配维护账号可以修改配置、确认告警管理员账号自己保存好。权限这东西平时不觉得重要出事的时候就是背锅和免责的分界线。工程备份也要制度化。开发完一个阶段就用 FUXA 的工程导出功能打一个包存起来跟版本号对应。我们后来还写了个定时脚本每天凌晨把工程数据和历史数据库目录整体压缩一份扔到备份盘里。对于小团队这就是性价比最高的容灾方案。6. 实测踩坑记录我替你先趟过的问题6.1 三个值得展开说的坑第一个坑是中文乱码。现象在 Linux 服务器上部署后浏览器打开画面所有中文标注全部变方框。原因是服务器本身没有装中文字体浏览器渲染字体时找不到字符就显示成占位符。这个坑前期完全想不到因为本地 Windows 开发环境根本不会缺字体。解决办法很直接安装系统里的中文字体包或者给两端统一指定一款常见中文字体。改了字体之后图元文本要统一规范别不同图元用不同字体否则画面风格很乱。第二个坑是 Modbus 读数莫名其妙。现象现场一个温度传感器的值在仪表上显示 25.6 摄氏度FUXA 画面上读出来却是异常负值或跳变的数字。排查过程花了不少时间先怀疑是 IP 和从站号配错检查后没问题再怀疑是地址偏移对照设备手册也没错最后发现是字节序配置和实际寄存器排列不匹配。现场工程师给的寄存器表不会明确告诉你字节序是高位在前还是低位在后只能通过试验来确定。我的经验是第一次接入新设备时先在从站端设置一个固定的、好识别的数值然后把字节序的各个选项切一遍看哪个读数最稳、最合理选中之后再批量建点。第三个坑是历史数据文件疯长。现象项目跑了两周突然收到磁盘空间告警。查看数据目录发现历史文件已经从几百兆涨到几个 G。原因当时图省事给大部分标签都勾了历史存储刷新周期又设得短数据被大量重复写入。解决办法只对关键参数和历史分析需要的点位开启存储把存储周期从秒级放宽到分钟级然后写好历史数据清理策略超过三个月的数据归档后删除。历史数据要有但不是所有数据都值得长期保存。6.2 踩坑速查表除了上面三个还有几个频率较高的坑整理成表方便新手排查现象原因处理方式页面打开空白浏览器缓存了旧版本硬刷新或清理缓存再重新登录编辑器报错、无法启动Node 版本过新或过旧切换到 LTS 版本重新 npm install反向代理后画面加载但数据不更新WebSocket 代理未开启在代理配置里把 WebSocket 直通流量放行运行模式点击控件没反应控件事件或属性绑定配置错误逐个检查绑定关系先在预览模式里测试单个标签画面能访问但登录不了初始账号密码被改过且遗忘重置用户数据或恢复工程备份6.3 给新手的排障方法论最后想分享一个通用排障思路开源项目出问题第一反应别是猜而是去翻日志。FUXA 启动时控制台会输出一堆信息通讯失败、存储异常、脚本报错基本都会留下痕迹。顺着日志大概率能精准定位问题。第二个思路是「最小化复现」。异常出现时不要在一堆标签和画面里找原因而是建一个最简单的场景一条链路、一个标签、一个控件看能不能复现问题。能在最小环境复现就能快速做排除法。不能复现大概率是配置量太大导致的边界情况这时候逐步加回来直到复现为止。很多 Modbus 类的问题都是这样做排查的。至于更深层的功能特性FUXA 毕竟是开源项目遇到文档没写清楚的地方直接去翻源码是最靠谱的路径。我曾在源码里查到某个控件的完整属性列表比文档列得还全。学会读源码开源软件在你的手上才真正变成「自己的工具」。最后再分享一点个人体会FUXA 折腾了这些天我的整体判断是它不一定能替代商业组态软件但在中小规模项目里它确实提供了一条高效、低成本的路线。尤其是那种甲方预算有限、周期紧又想远程看数据的场景FUXA 几乎是刚需方案。真要动手做第一件事不是急着搭环境而是想清楚自己的点位规模、通讯协议、数据保留周期。把这些定下来再带着需求去配设备、建标签、画画面速度会快很多。过程里千万记得及时导出工程备份这个习惯救过我很多次。后面如果再深入我会考虑自己写几个自定义图元或者给它的协议层做一个扩展。开源的好处就在这——工具不够用那就自己补一块。希望这篇介绍能帮你少走几条弯路顺利把第一套界面跑起来。