投稿作者:jason8888
AtomGit 平台 IOT-Tree Server 项目作者
引言
IOT-Tree Server 也是我目前唯一一个开源项目。从第一次提交代码到现在已经 4 年,现在回头看整个软件的功能,连我自己有时候也会惊叹,这是我搞出来的么?感觉自己这些年,不断的积累改进,弄出了一栋大楼。如果当初以现在这个软件为目标,那很可能就不敢开始了。
在此先有个感慨,持续专心做一件事真的很重要!!!
先给大家看一下这个软件使用界面吧
一个实际的产线数据采集项目
一个实际的机房监控项目
1|开发这个软件的缘由
首先,我是个 Java 程序员,并且担任架构师和研发经理多年。开发软件到一定时间之后,总感觉缺点什么。网络上看到人家做的四轴飞行器、各种好玩的设备,心里那个痒啊!因此,在疫情之前的一些年,我除了软件开发之外,还干了如下这些事:
- 自学电子技术,玩单片机,电路设计。学习各种单片机通信协议,什么 I2C、SPI 之类的,也做过一些数据采集电路,并用到了一些项目中——结果就是,设备故障率怎么那么高,汗!
- 后来朋友介绍了一些物联网项目,需要对接工业控制领域设备获取数据到云端,云端使用 Java 开发管理平台软件。接触工业现场设备多了之后,我才意识到,我之前做的一些采集设备就是玩具——工业设备的研发,需要一颗安全可靠的敬畏之心:真正好的产品,主线功能实现投入占比很低,设计者需要对各种可能的异常情况做应对,也需要考虑生产的效率和成本。还需要时间的考验持续改进。
我搞电子电路是半路出家,纯业余选手,就决定不继续往下搞了。
2021 年的疫情期间,特殊时期只能呆家里,闲不住的我开始反思自己应该干点什么!
首先,我最擅长的还是软件开发,特别是对 Java 的理解,得发挥出我的优势;
其次,如果做个传统的纯软件系统,我兴趣又不大,因为类似工作流引擎、消息中间件之类的,我都尝试着做过。
再次,在工业现场对接设备时,我曾经实现过最简单的 Modbus 通信协议,可以从一些串行接口设备中获取数据;也曾经使用开源 OPC DA 库对接组态王之类的组态软件。但对于各种 PLC,当时由于不了解,只能借助第三方软件 —— 这一直是我心中的一根刺。
能不能我搞个软件,把这些对接都搞一起呢?搞一起之后,我再弄些更好用的接口(比如 RESTful)不就可以让类似的物联网项目轻松实现了么?
于是我开始查找分析各种 PLC 的通信协议资料,最终得出结果:就干这个了。
2|软件名称为何是 IOT-Tree Server
当时物联网 IOT 这个概念很流行,所以我这个软件就以 IOT 开头,那为什么跟着一棵树(Tree)呢?这里我发个开源软件首页一张图:

软件先要对接设备,吸收数据养分——这就是树根部分;汇总之后数据要被顶层各种分析使用获得价值——这不就是树上部分的枝叶和花果么。
另外,我不准备为这个软件做专门的客户端管理工具和使用工具,web 管理端开发既轻松又方便使用,因此这个软件本身是个独立运行的 Server。
所以,最终取名为:IOT-Tree Server
3|这么些年的开发心路历程
3.1 树根部分开发(设备通信和驱动)
说实在,最初设计软件框架的时候,以为这就是软件的全部了。只需要统一设备接入之后的数据组织结构,剩下的就是不断添加各种设备驱动了。
我最先实现的设备驱动是 Modbus RTU,因为之前做过,但放到这个产品级的开源软件中时,相对而言之前实现的设备对接程序通用性和完整性就太差了。这个协议看着简单,但要考虑更多的如下问题:要能够对接所有的 Modbus 设备,能够自动适应各种不同的数据点地址集合,要能够支持各种细致的访问控制。总之,万事开头难!
实际项目是我的一个重大推动力。
Modbus RTU 协议完成差不多之后,就碰到一个项目要对接西门子 S7-200 PLC,并且把数据发送到用户的云端系统中。幸好之前了解过这个 PLC 的 RS485 口的 PPI 协议,感觉能搞定,就硬头皮直接答应用户要求。然后,赶快弄了个旧 PLC 开始没日没夜的西门子 PPI 驱动开发(驱动没出来,心里就没底,也就睡不着觉了啊),中间甚至简单学习了一下西门子 PLC 的编程。还好辛苦没白费,顺利完成了用户要求(并且程序运行一直很稳定)。
这个项目的成功,给了我很大的信心。同时也深刻理解,软件要成为好产品,用实际项目打磨是最好的选择。
3.2 交互界面的开发支持
在上面 PPI 协议完成并成功用到项目中之后,我心态有点膨胀了。在用户中控现场,看到工控机上的组态软件可以自由地制作现场监控画面,稍微研究学习了一下,反思自己之前 h5 canvas 开发经验,感觉我也可以搞定,顺便就决定在软件中优先加入 hmi 功能(纯 web 展示),并且要完全支持浏览器中在线编辑。
这是一个巨大的坑,因为监控画面由各种基础图元组成,我一开始使用 js 实现基础图元绘制,接下来就是各种问题各种烦躁。幸好幸好后来了解并学习 TypeScript,并立刻以这个重新开始,这个改变使得前端绘图代码结构定义和严谨程度接近 Java,可以充分发挥面向对象的优势,这才让整个开发过程顺利推进——大型前端代码工程强烈建议上 TypeScript。
整个开发过程不用多说,基本也是没日没夜,特别是一开始,充满了激情和动力。基础功能完成之后,自己尝试制作了一个简单的 demo,在这个 demo 实现过程中,本身也是对这段劳动成果的测试——总之就是感觉各种难用。
还是很幸运,又有一个自动化升级小项目:用户要求在厂区对远程的泵房进行自动调配,需要根据厂区运行工况,自动判断是否要启动远程的泵房。此项目我不仅加速实现了 IOT-Tree 基于 JS 脚本的定时任务(Task)功能,同时,使用我新做的交互界面功能,给用户画了一个简洁的总图(非大饼),没想到用户感兴趣也要了。于是,围绕这个项目,直接把我这些新做的功能全部锤炼了一遍。
项目实施过程本身也即是 IOT-Tree 软件各方面功能的实际演练。我只要发现哪个地方用的不爽,那就花大时间改进。其实整个项目 1-2 周就能够完成,但我前期就花费了 2-3 个月自我折磨的准备。
完成此项目,我才感觉 IOT-Tree 才勉强有点产品的样子了。
实际项目的监控画面
3.3 消息流的实现
随着驱动的增多,树根部分框架越来越稳固。我的主要精力慢慢往树上部分转移。但我也克制,不希望这部分内容变成各种纷繁复杂的业务需求,只希望能够提供顶层业务系统需要的支撑功能即可。
一开始专注于标签数据的事件(含报警)生成策略和后续处理(handler),为此实现了一个可视化的简单框架(触发-处理框架):事件触发节点 + 后续处理 handler,并实现了一个直观的可视化展示。
其中,事件的触发可以支持规则、js 脚本等内容;而 Handler 是个抽象,可以不断积累各种实现,如 MQTT 发送、写数据库等等。弄出这个框架主要目标是让软件使用者在后续数据基本处理上直接可视化配置即可——更复杂的就不管了。
触发-处理框架(已弃用)
但总感觉差点意思——还是有点弱了,唉!
直到一天我突然看到 Node-RED 这个 IBM 搞出的软件,一下子就被吸引了,原来差点意思就是和这个相比差了。这个流程图很简洁,但比我的“触发-处理”框架强大多了。并且我有着组态画面实现经验,感觉照着实现一个类似的很容易。
美工界面设计是我的极弱项,因此我就边学习 Node-RED 边抄作业(不知道是否丢人)。但从中我发现了 Node-RED 节点粒度太细——试图使用流程能够完全替代程序的开发,这和我的理念不同。既然用到了流程,那就不能使得使用过程比实际的 JS 脚本更复杂,我设计的消息流程节点,除了基础几个辅助节点之外,必须是中粒度复杂程度。使用过程要尽可能的使流程简单。
另外,我还改进引入模块节点概念,使得一些节点只能依附于模块节点。这样能够更好的表达功能集合和资源对象。如关系数据库模块节点,内部可以包含只对自己指向的数据库资源进行各种操作。
这是一个标签触发报警自动进行记录的流程。
有了消息流,之前的定时任务、“触发-处理”框架就都被覆盖了。同时,从整体结构上也保证了 IOT-Tree 的两大概念,树根部分和树上部分。树上部分就是这个消息流。
3.4 ARM Linux设备中的移植
IOT-Tree Server 整个软件核心都基于 Java 实现,如果没有充分利用这个跨平台特性,那实在可惜。因此,我整了几个嵌入式 ARM Linux 开发板和模块,内部资源足够运行 Java 虚拟机尝试移植。没想到出奇地顺利。并且经过长时间测试之后,很快就被用到了用户现场——直接使用以太网口对现场的 PLC(RS485 口已经被触摸屏占用)进行数据获取,然后转换成 Modbus 模拟设备,并通过设备自带的 RS485 口对接 DTU 接入云端。
有了这些小体积的设备支持,IOT-Tree Server 的能力又被放大,可以直接把 ARM Linux 设备变成强大的物联网边缘设备或协议转换网关。

这是一个体积最小的工业级 IOT-Tree Edge 模块
4|未来改进计划
4 .1 更多接入、驱动和协议支持
目前 IOT-Tree 支持的设备驱动有 Modbus RTU、Modbus Tcp、西门子 PPI、西门子 TCP/IP Ethernet、三菱 MC Ethernet TCP、欧姆龙 FINS Ethernet TCP。已经能够覆盖大部分主流的 PLC。
接入驱动有:OPC DA、OPC UA、HTTP Client、HTTP Server URL、MQTT、WebSocket 客户端等。
直接支持的数据转换输出有:OPC UA Server、BACnet Device 等。
这部分内容越丰富,树根部分就越强大,越能适应各种现场。
4 .2 更多消息流功能节点
树上部分消息流框架已经完善,然而对于数据的后续使用:如推送、存储、分析等还是很大的适配空间。比如需要支持更多的非关系数据库、支持更多的通信中间件、支持一些模型的整合。
4 .3 让 hmi 在线编辑更好用
虽然在线组态画面已经有足够的功能,但从易用性来说,离专业的画图软件还有差距。这也算是还有很大的提升空间。
4 .4 性能优化
未来有计划使用 GraalVM 进行本地化编译,能够适应更低资源的 ARM Linux 设备。
4 .5 专业版计划
IOT-Tree Server 开源版本在你自己的项目中(不做二次商用分发)是免费的。但我们接触的一些行业用户有着更高的需求。
因此,未来有计划根据不同行业的通用需求,定制各种方向的专业版(商用但有着超高性价比的标准产品)。以此也为我们未来的团队增加收入,形成良性循环。
希望 IOT-Tree Server 软件和其他很多开源软件一样,能够为你们带来极大的方便。减少时间成本,抓住项目机会,受益多多,收益多多!
📫 项目地址: https://atomgit.com/jasonzhu8888/iot-tree?isLogin=1
