紫金桥软件二十二周年：组态、实时数据库与工业软件的长期主义

紫金桥软件二十二周年——致用户的一封信亲爱的用户、合作伙伴以及所有关心工业软件的朋友们二十二年前的某个傍晚我看着控制室里的一排仪表数据在显示器上跳来跳去突然冒出一个念头要是能让工艺人员像搭积木一样把生产流程的画面拖拽出来把报警、趋势、报表都自动连接上那该多好。那天晚上这个念头还只是一闪而过后来它慢慢长成了紫金桥软件。今天我坐在这里写信窗外是熟悉的工业区灯光电脑里还开着测试工程心里很感慨这个产品、这支团队已经和各位一起走过了二十二个年头。二十二岁对人来说是大好年华对工业软件来说更像是一场漫长跑道的折返点。很多朋友是从最早的版本就开始用我们产品的从水处理、电力、化工到油气管道从车间级监控到工厂级调度一个个现场把紫金桥软件从青涩打磨到了今天。这封信不想写成官方通稿我只想以一个开发者和运维者的身份跟各位聊聊这些年我们做对了什么、做错了什么以及未来打算往哪个方向走。1. 二十二年前为什么我们偏偏要做组态软件1.1 从一台上位机开始的“捣鼓”二十多年前工业现场的监控软件还谈不上“生态”两个字。PLC和仪表已经很普及但上位机软件大多跟着硬件捆绑走换一个品牌设备往往就要换一套软件画面风格、数据格式、报表逻辑全都得重新学。最让人头疼的是现场工程师明明只想要一个简单的水位曲线却被迫去学底层图形编程出图慢、改起来更慢。我当时接触过一个水厂项目配电室里的上位机跑着一套定制程序画面里只有几个数据框连流程示意都没有。操作员想看某个泵的真实运行状态得靠现场打电话回来问。那个项目最终交付时客户技术人员问了一句“下次如果换个泵我们能自己改画面吗”这个问题我记了很多年。组态软件存在的意义就是回答这个“能”——把画面编辑、数据绑定、脚本逻辑这些能力还给用户而不是锁在开发者的电脑里。1.2 选择“组态”而非“纯定制”是想解决用户的周期和成本之痛很多人问过我当年为什么不走纯项目定制的路定制开发来钱快需求边界清楚看起来也更“高级”。但我始终觉得工业现场的需求虽然千差万别底层的共性其实非常强都要采集数据、都要展示画面、都要报警、都要趋势曲线、都要报表、都要和PLC通信。如果每个项目都从零开始写客户付的每一分钱都在为重复劳动买单那不是在做产品是在做软件外包。组态的本质是把工业监控里80%的共性能力预置成积木剩下的20%留给用户自己去搭。这么设计的好处很明显项目周期从几个月缩短到几周客户后续改造不用再找原厂商自己动手就能完成。当然代价也很现实——产品必须覆盖足够多的行业场景协议库要足够丰富稳定性要经得起各种恶劣现场考验。这正是我们坚持二十多年的原因。关于选型我认为可以给刚接触组态软件的朋友一个判断标准真正把用户当作长期伙伴的厂商会主动把编辑权限开放给你而不是用复杂的工程加密把你绑定住。2. 二十二年里产品形态发生了哪些实质变化2.1 从单机画面到分布式实时数据库早期的组态软件核心任务很简单把PLC的数据读上来在画面上显示记录历史曲线。单机部署足够应付大多数小型站所一台工控机、一块串口卡、一根通信线画面做出来能跑就行。但随着工厂规模变大单机模式的瓶颈很快显现数据分散在多个操作员站彼此不知道对方采集了什么服务器一重启历史数据断档多个客户端要访问同一份数据时连不上、抢锁、冲突轮番出现。所以我们很早就把工作重心从“画画面”转向“做数据中心”。这里说的数据中心不是传统关系数据库而是一套专门为工业实时数据设计的实时数据库高频写入、长时间存储、按时间切片查询、百万点级别的容量规划。实时数据库最大的特点是把“最近一段时间的当前值”和“历史归档值”统一管理起来快照和历史趋势可以无缝衔接。你在画面上拖动游标看十分钟前的曲线系统不会先查硬盘再慢慢返回而是从内存缓冲和归档文件里按时间索引定位几毫秒内给出结果。有人会问为什么不用MySQL或PostgreSQL存历史数据关系数据库擅长事务性操作比如订单、库存每次写入有完整事务保障。而工业采集是高频追加型的写入动辄每秒几万点关系数据库的索引更新和锁机制会成为瓶颈。实时数据库的做法是先在内存里多级缓存再按块批量落盘配合专门的压缩算法把存储成本降得很低。这个架构直到今天仍然是大型SCADA系统的核心生产力。2.2 协议栈从“够用”到“开箱即用”通信协议是组态软件最容易被人忽视、也最容易翻车的部分。早些年的项目很纯粹Modbus RTU走遍天下串口一接地址表一填数据就上来了。后来现场越来越复杂西门子的S7协议、AB的CIP、欧姆龙的FINS、三菱的MC协议、电力行业的IEC 104、楼宇的BACnet、物联网场景的MQTT、还有各种PLC厂家私有协议……如果每来一个新设备就临时写驱动用户等不起我们也累死。这些年我们做了无数次取舍结论是协议适配库必须当成独立产品来建设。我们的做法是先梳理行业里Top级别的设备品牌和型号清单再按优先级逐个开发并做真机测试。特别注意不能在实验室里“想当然”不同批次固件的PLC报文细节可能完全不同只有拿真机点对点调过驱动才算数。每适配一个协议我们都会沉淀一份通信测试报告记录波特率、字节序、地址映射、异常码这些资料是驱动质量的底仓。到现在我们的协议库覆盖了几乎所有主流PLC、仪表、DCS、板卡和网关。但我不认为“协议多”是终点好用才是终点。用户不该为“选哪个驱动”而困惑。所以我们在新版里做了驱动自动识别根据设备型号自动匹配通信参数能省掉很多现场配置时间。2.3 从CS到BS、从桌面到Web端到边缘二十二年前所有客户都习惯装一个Windows客户端但现在很多系统集成商明确要求浏览器访问、移动端查看甚至把部分计算下沉到边缘网关。组态软件如果只守着桌面阵地迟早被时代抛下。我们做Web组态产品线的时候内部有过很大争论是把桌面版画面直接转换输出成网页还是砍掉重来做一套Web编辑器前者开发量小但体验受限于本地软件思维后者工程量巨大却更贴近Web生态。最终我们选了后者只用一套图形模型同时支撑桌面端和Web端渲染。这意味着工程师在桌面版里画好的画面可以直接发布到Web端显示不需要二次制作。数据链路也做了适配Web端通过专有的数据服务接口订阅数据断线自动重连并支持按权限订阅数据。边缘侧是我们另一个观察了很久的方向。现在的项目里网关设备越来越便宜算力也很可观。与其把所有数据都拉回中心再计算不如在边缘侧先做过滤、清洗、阈值判断只把有效事件上送。组态软件可以运行在紧凑型工控机甚至容器环境里完成轻量级数据采集和本地展示。这套组合下来中心压力小了断网期间现场也能独立运行。3. 用户教会我们的几件重要的事3.1 稳定压倒一切性能要为稳定让路做工业软件久了越来越清楚一个朴素道理现场最怕的不是功能少而是莫名其妙重启、丢数据、卡界面。有一次我们在某化工厂做升级新版本引入了一个高效的多线程调度模块压测数据非常漂亮内存占用下降了30%吞吐量翻了一倍。结果一上现场第三天深夜系统出现偶发死锁。排查了整整两天最后定位到是第三方驱动回调的线程模型和我们的调度模块冲突。那次事故让我们定下一条产品铁律核心架构变更必须有至少两个完整大版本的局部验证期任何尝鲜功能默认关闭由用户在项目里按需开启。稳定性不是靠测试工程师意志力堆出来的而是靠产品策略主动让步换来的。性能指标可以放到第二位把“跑不死、不丢数、能自恢复”放在第一位。3.2 现场工程师不需要“炫技”需要“少折腾”我见过很优秀的组态工程画面配色精美动效流畅脚本写得很聪明也见过很“朴素”的工程只有数据框、状态灯和一张工艺流程图。问操作员哪个好用答案常常出乎意料——他们喜欢后者。因为现场工程师关心的不是软件玩出了什么花样而是交接班时扫一眼就能看清状态出问题时能在最短时间内找到报警源头。这里我特别想强调“画面即效率”。组态画面设计得好不好直接影响故障处置速度。颜色要克制状态要明确重要报警要能在视觉上跳出来操作按钮要放在最顺手的位置。我们后来在文档和示例工程里持续传递这个理念引导用户做“克制的设计”而不是把每个图元都装饰得花里胡哨。3.3 文档和售后往往比功能更能决定口碑有一年做满意度回访结果出乎我们意料功能评分排名第一的产品线总体满意度却低于第二名。拆开数据一看差距在文档和响应速度上。那次之后我们成立了专门的文档组把每个驱动的接线说明、寄存器表、常见故障码都整理成有目录的PDF并在工程模板里附上注释说明。售后响应也从“工单排队”改成“技术值班远程协助优先”核心研发人员按周轮值对接现场疑难问题。说句实话很多用户不是因为我们的功能最全才留下而是因为凌晨两点出了状况电话打过去有人接、能听得懂、愿意一起排查。这种信任比任何市场投放都值钱。4. 组态软件的“核心细节”值得你多了解一点点4.1 画面组态图形对象和动画连接的关系这是组态软件最直观的核心。用户从图元库拖出一个阀门再双击它打开“动画连接”配置页把“颜色”关联到一个开关量“旋转角度”关联到一个模拟量这个图元就“活”了。本质上是图形对象的一个属性和一个实时数据的表达式建立了映射。理解这个概念你会发现组态并不神秘。我建议新手做动画连接时先从简单的状态量开始练手。比如用一个圆形图元代表泵把它的“填充颜色”连接到一个“运行/停止”变量里写好为1显示红色、为0显示灰色。搞定之后再试模拟量驱动位移、旋转、数值显示。规则很简单——但正是这些简单的规则组合起来才能搭出复杂到整条生产线的动态仿真。所谓“组态”就是对“属性-数据”映射关系的编排。4.2 数据处理历史存储、压缩与回补很多用户问为什么历史趋势曲线在半夜会出现一段空白多半不是软件坏了而是通信链路短暂中断、数据没有补传。这里涉及组态软件里一个重要机制数据回补。PLC和上位机断开后上位机在缓存区记录断点时间链路恢复后驱动自动向PLC询问缺失时间段的数据值再回填到实时数据库。这套机制要求驱动具备“按时间戳查询”的能力也要求存储端能接受乱序写入。存储压缩同样值得一提。工业历史数据不像文本文件它充满了反复出现的相似数值比如一个液位在90%上下浮动。我们用的压缩算法是结合死区判断和旋转门压缩的思路只在数值变化超过一定阈值时记录数据点平缓段用起始值和结束值表示。这样一年下来的历史文件可能只有传统存储方式的十分之一大小查询速度却更快。4.3 通信层驱动、冗余与故障切换通信层是组态软件的“血液循环系统”。一条完整的采集链路通常包含物理设备、通信网关、上位机驱动、数据服务接口四个环节。任何一个环节不稳画面上的数据就会跳变。我们处理通信有一个原则驱动要做到“断线恢复后状态自动对齐”——不只是重连TCP链路还要重新校验设备在线状态、时间基准和数据时间戳防止旧数据覆盖新数据。冗余是大型项目的常态需求。双机热备、双链路、双PLC冗余不同冗余结构对应的组态策略完全不同。我们的做法是提供透明的“对象冗余”机制用户在组态里定义一个数据对象底层同时绑定主备两个通道当主通道卡死或超时系统自动切换备用通道读取整个过程不丢数据。切换时间要控制在百毫秒级这个指标直接影响工艺联锁的可靠性。给工程人员的建议冗余方案的验证一定不要只在软件里做模拟测试要把物理线路断电、设备重启、交换机断网这些真实故障逐一演练一遍。很多冗余失效案例都出在中间网络设备上而不是组态软件自身。5. 站在二十二年的路口我们把宝押在什么地方5.1 自主可控不是口号而是每一行代码的取舍过去很长一段时间里国产组态软件总被拿来和国外产品比较比功能、比性能。这些年行业环境变化很大越来越多的用户开始关注“自主可控”这四个字。但在我看来自主可控不能只停留在“不依赖某一家国外厂商”的政治表态上。真正的自主可控体现在源码级别核心图形引擎、实时数据库、协议栈解析、脚本运行时每一层都可以自研和自维护出了问题能自己定位修复而不是拿到一串堆栈只能求助上游厂商。这条路需要耐得住寂寞。自研图形引擎要处理大量显示细节一个模糊、闪屏、字体缩放问题就可能耗掉一个工程师好几周自研实时数据库更是烧钱的深坑。但二十二年的经验告诉我们把核心技术握在自己手里遇到突发状况才有底气。我们会继续加大在跨平台内核和Web渲染引擎上的投入逐步摆脱对特定操作系统的依赖。5.2 开放生态让用户拥有更多可选择性工业软件不能做成封闭城堡。用户的数据永远属于用户软件只是工具。所以我们一直重视开放接口支持OPC DA/UA、Modbus、MQTT等标准协议提供API和脚本接口方便上层MES/ERP系统取数。未来我们还会进一步完善SDK让合作伙伴可以在紫金桥软件之上开发自己的行业插件。开放生态还有另一层含义支持多种部署形态。只要用户愿意可以把采集网关装在边缘盒子把实时数据库装在私有云把Web展示发布到公网域名。我们不强制绑定硬件也不锁定部署方式让用户在架构设计上有充分自由度。5.3 以低代码为前提降低工业软件开发门槛组态软件本来就是“低代码”的鼻祖。但过去低代码的门槛仍然不低用户至少要理解“变量”“脚本”“驱动通道”这些概念。我们下一步要做的事情是让“描述式组态”成为可能。举个例子用户输入“将三号罐液位超过80%时打开进料阀”系统能够基于已有的设备模型自动创建变量、逻辑、报警和画面跳转。这中间用到的规则引擎和语义解析目前原型已经跑通我们正在工程现场打磨。我始终认为工业软件的未来不是取代工程师而是让工程师把更多精力放在工艺优化和异常判断上把重复性的“配置连接”交给工具去完成。这条路值得再走十年。6. 一些给用户的贴身经验写在信的最后6.1 升级别急“小步快跑”才是稳妥做法每次发布新版总有人急着把生产系统升上去。我特别理解这种尝鲜心态但工业现场真的没必要追新。安全的升级路径是这样先在离线环境用历史数据回放功能做验证再看新版本的驱动、脚本接口有没有不兼容变更最后选一条非关键产线做灰度运行观察一至两周再全量切换。如果现场运行的是稳定老版本且没有新增需求完全可以不升级。很多用户的生产系统用了七八年也没问题这说明版本稳定也是一种价值。我们发布新版本的同时会保留常见老版本的补丁通道就是希望用户有选择权而不是被强制拉新。6.2 把故障预案写进组态工程而不是只指望售后我见过太多工程画面精美、报表齐全但唯独没有做“故障预案”。一旦通信断掉、服务器主备切换操作员只能干瞪眼。建议每一位做组态工程的朋友在建工程之初就把异常场景列为功能需求通信中断时画面上的数据是否显示为灰显报警要不要在本地闪烁提示历史断点缓存能容纳多长的数据量备用服务器接管后需要多少秒内完成告警把这些用工程逻辑提前定义好现场故障发生时才不会慌。另外还有一个小习惯值得养成给工程文件做带日期的定期导出备份并保留至少三个滚动版本。很多现场问题最后是靠回滚到前一天版本的工程文件才恢复生产的。这一条几乎不要成本但远比任何售后响应都及时。6.3 评价一款组态软件的三个指标如果你正在选型或者准备替换现有监控系统我的建议是别看演示Demo的流畅度而是看三件事。第一协议驱动库与你的设备清单是否匹配并确认这些驱动是否经过真机验证第二历史数据存储的长期运行表现能否在连续运行一年后仍然保持稳定查询速度第三出问题时的支持能力有没有同行业客户的实施案例和说得出具体细节的应急预案。把这三项问明白了比看一百页宣传册都管用。在这二十二年里我们收到了很多用户的建议也拒绝过一些看起来很“诱人”的需求。拒绝的原因往往有一个共性需求只对单点有价值却可能损害产品的整体稳定性。做工业软件最重要的是分寸感——什么该做什么不该做什么需要沉淀多久才能做心里要有一本账。写完这封信打开测试机的监控页面屏幕上的趋势曲线像往常一样平稳地向前延伸。这条线从二十二年前画到今天还将继续画下去。感谢每一位信任紫金桥软件的用户你们的每一次反馈、每一个深夜电话、每一份现场故障报告都是这个产品最扎实的养分。接下来的路我们仍然选择和你们站在一起在每一个需要精准、稳定、可靠的工业现场守住这条数据的长河。