aiots物联网平台

Appearance

aiots 是什么 ​

aiots 是一款 AI 驱动的工业物联网开发平台, 核心思路是模型驱动而非代码驱动--配配置、不写代码, 就能对接设备、采集数据、设置告警。AI 落地所依赖的底座能力是平台的现成能力, 见文末「为 AI 而设计的底座」一节。

一个工业物联网项目, 不管什么行业, 大概都是这几件事: 把设备连上来、把数据采上来、异常了能找到人、最好还能自动处理、最后让人看得见。这些事每家工厂都要做一遍, 而且做法大同小异。aiots 把这些重复的通用活儿做成了平台现成能力, 你只定义"采什么、什么时候告警、满足什么条件做什么动作", 剩下的交给平台。

下面按一个项目实际的推进顺序, 把平台的各项能力讲清楚。

📖 上手教程: 快速开始

设备接入: 内置 17 种工业协议驱动 ​

接设备是第一步, 也是传统做法里最费人的一步--每种协议写一套驱动, 调通信、抠字节序, 一个协议一个坑。aiots 把这步做成了选配: 平台内置 17 种协议驱动, 覆盖常见的工业场景。

  • 通用协议: Modbus RTU/TCP、OPC UA、MQTT、HTTP--电表、温控表、传感器、智能硬件大多走这几样
  • PLC: 西门子 S7、欧姆龙(HostLink/CIP 双方式)、三菱 FX5U、罗克韦尔、汇川、松下--市面主流品牌都在列
  • 电力: DLT645 电表、IEC104、IEC61850--国网标准、变电站、光伏风电场景
  • 透传与数控: DTU 透传、Fanuc CNC 数控机床

使用上, 同型号设备配一份产品模板, 后续整机复用。Modbus 采集还做了批量优化: 连续地址自动合并成一次读, 不用一个点一条指令地轮询, 通信效率和对设备的压力都不一样。

没网口的老设备也有路。车间里那台服役十几年的注塑机、锅炉, RS485/RS232 串口接一个 DTU 盒子, 串口数据转 TCP 或 4G 上平台, 驱动是现成的透传驱动。大量"设备太老不值得换"的存量改造, 走的就是这条路。

组网方式上, 平台区分三种设备类型: 直连设备、网关下的子设备、只做转发的网关设备。子设备的数据经网关汇总上报, 网关本身不产生数据--和现场真实的组网结构对得上, 不会为了进平台把网络拓扑拧成别的形状。

没听过的私有协议也不用慌。平台留了 SPI 驱动扩展点: 私有协议只要跑在 TCP 或 UDP 上, 按接口规范写一个驱动组件挂进去, 物模型、告警、存储、展示这些平台能力对新协议照常生效。协议是新的, 后面的活儿不用重来。

物模型: 整个平台的中枢 ​

理解 aiots, 关键是理解物模型。每个产品在平台上有一份物模型, 定义这个型号的设备"有什么":

  • 属性--数据点。温度、电流、压力, 以及开关、状态字这类信号
  • 功能--可下发的指令。开机、停机、设定阈值, 支持输入/输出参数
  • 事件--设备主动上报的信号

属性支持 9 种基本数据类型, 另有三种容器类型处理工业现场的特殊情况: json 容器把嵌套 JSON 自动展开; bit 容器把一个 16 位状态字按位拆成多个独立开关量, 每个位可以单独配告警、单独入库; group 容器把相关属性分组管理。

还有两个贴现场细节的设计。属性字典: 设备上报的是编码值(0/1/2), 字典把它映射成可读名称(运行/待机/故障), 页面上看的是人话不是数字。控制自动拆分: 一个既读又写的开关属性, 配上字典后自动拆成"状态显示 + 控制按钮"两个呈现, 移动端直接变成可点的按钮。

采集频率用频率标签控制: 温度 5 秒采一次、电量 1 分钟采一次, 不同属性不同节奏; 再配合采集器按设备组分层调度, 一个车间只采本车间的设备, 采集负载精细可控。

物模型配好之后, 采集、存储、告警、展示、App 端全平台都认这一份定义。这就是"模型驱动"的含义: 加采集点是在物模型上加属性, 设告警是在属性上配阈值, 换一批同型号设备整个复用--传统做法里这些是改代码、测试、发版, 在 aiots 里是页面配置。

告警体系: 告警与指标分离 ​

告警是工业场景里最影响信任感的功能--报多了没人看, 报漏了要出事。aiots 在这点上有个刻意设计: 告警与指标分离。

  • 告警: 阈值超标、需要人处理的事。入库记录、推送通知, 有人处理有人闭环
  • 指标: 偏高、偏低、正常这类状态。只在前端显示标签, 不产生记录、不推送、不扰人

不这么分的后果很常见: 半夜推一堆"温度偏高"通知, 值班员第三天就把通知静音了, 真报警反而没人看见。分离之后, 推送到手机上的每一条都值得看一眼。

告警级别做了七级枚举, 从严重故障到仅展示全覆盖, 按等级决定通知方式和处理优先级。配置入口有两个: 简单场景直接配在物模型属性上, 配属性时顺手把阈值设了; 复杂场景用多属性组合告警--温度高且风机停转才报, 且/或任意组合, 把误报压下去。

配套的还有: 告警模板自定义通知内容, 设备上下线自动告警不用配置, 告警记录按设备/时间/级别筛选查询, 告警类型区分来源一目了然。出过的事、谁处理的, 平台里都有迹可查。

数据中心: 从查数到定位问题 ​

数据采上来存住只是开始, 数据中心解决"怎么用"。

历史数据按属性维度查, 排查单个数据点的走势; 产品数据按产品维度把一台设备的全部属性合并成行, 横向看设备全貌; 通用报表把多设备多属性拉进一张即席对比图, 不同车间的同一指标放一起看。

重点说指标分析。它从告警出发, 按五层逐级下钻: 先看告警卡片看板掌握全局, 再看单点位趋势找突变时刻, 然后同设备其他点位对比、跨设备横向对比, 最后做多维关联分析。现场排故障最耗时的是"不知道问题出在哪一层"--是传感器抖了、设备真坏了、还是通信断了--指标分析把这个逐层定位的过程做成了页面功能, 告警发生时刻前后的关联数据自动摆在一起, 不用再翻几张表对时间戳。

脚本引擎: 内嵌数据管道的三道关卡 ​

平台再全, 也会碰到配置覆盖不到的非标需求。aiots 的答案是脚本引擎--不是外挂的工具, 而是内嵌在数据管道里的三道关卡, 采集、解析、联动三个环节各有一道, JS 语法, 页面里写完即生效。

第一道, 数据过滤--在采集和入库之间决定"什么数据值得存"。变化检测入库: 值变了才写库, 不变的重复值直接过滤; 时间间隔过滤: 高频采集、降频存储。存储压力和查询效率都受益。

第二道, 数据解析--把原始字节变成业务值。类型转换、字节序换算、多地址复合计算、一条报文拆出多个属性(分组属性), Modbus 点表里那些绕人的换算都在这层解决。

第三道, 联动脚本--规则配不出来的复杂自动化逻辑。连续超温才告警, 瞬时抖动不算; 多传感器交叉验证再预警, 压误报; 产线计数满自动换箱; 甚至 PID 闭环调节做恒温恒压控制。还有功能解析管下行方向: 下发指令的参数帧动态组装, 应答不同设备的指令差异。

三道关卡的意义在于: 非标需求不再意味着"改后端、等排期、走发版"。懂业务的实施人员自己写几行脚本就处理了, 这是平台把"最后一公里"留给用户的方式。

计算属性: 原始值变业务值 ​

单独说一下计算属性, 因为它最常用。电表采上来的是电压、电流, 考核看的是功率、电费; 流量计上报脉冲数, 报表要的是累计流量。在物模型上写 JS 脚本, 采集完成后平台自动把基础属性算成业务字段, 公式改了页面改, 即时生效, 不动采集逻辑。统计汇总、持续累加这类通用计算也有现成支持。

场景联动: 设备间的自动化 ​

场景联动就是 if-then 规则引擎: 条件满足, 自动执行动作。条件支持多属性且/或组合; 动作可以是指令联动(自动下发控制指令)、通知联动(短信/邮件/钉钉)、多个动作串行执行。配合执行器的 cron 定时能力, 定时巡检、定时采集、班次报表触发都做得出来。

和单属性告警的分工是: 简单阈值告警配在属性上, 跨设备、多条件、要执行动作的自动化放场景联动, 各司其职。

可视化: 组态、大屏与运行管控 ​

组态编辑器拖拽绘制工艺流程图, 设备状态实时映射到图元上, 管道通了没有、哪个阀门开着, 一眼扫完。官方大屏模板开箱即用, 不想从零画就套模板, 大屏素材统一管理、上传复用。

日常管控有运行展板汇总全厂设备概况, 电子地图按地理位置看设备分布--多园区、多站点的主管用得上。

移动端 App: 现场在手机上 ​

管理端之外配套移动端 App, 和管理端共用同一套物模型, 定义一次两端一致。首页统计卡片打开就知道有没有异常, 最新告警第一时间推送; 设备详情页五个 Tab 把设备信息装全; 高频控制功能标记为控制状态后在 App 首页直接执行, 指令执行用自定义弹框, 现场操作不用回工位开电脑。App 用户走 Token 认证、自动续期。

开放与集成 ​

数据不是只能留在平台里。开放平台提供 AppId/AppSecret 认证的第三方安全取数接口, MES、ERP 这些上层系统按需取; MQTT 数据转发把数据转发到其他 MQTT 系统。用户体系支持微信/支付宝第三方登录绑定, 菜单权限按角色控制。

部署与扩展 ​

平台从第一天起按私有化部署设计: 部署在工厂自己的服务器上, 采集、存储、告警厂内闭环, 数据不出内网, 断外网照常干活--这对内外网隔离的生产环境是刚需, 详见私有化部署。核心框架已开源, 代码可审计。架构层面, SPI 扩展点不只给协议驱动留, 整体按可扩展设计, 二次开发有清晰的边界。

设备调试支持手动采集、下发验证, 配合指令日志, 通信问题、解析问题现场就能排查。

为 AI 而设计的底座 ​

aiots 定位里的"AI 驱动", 落在脚本引擎、物模型、数据管道这三项现成能力上。逐个说清楚它们和 AI 的关系, 以及沿着它们能走到哪。

脚本引擎: AI 最擅长的协作形态。平台把数据处理逻辑做成了系统内嵌的脚本--数据过滤、数据解析、场景联动, 都在页面里写, 写完即生效, 不发版、不改后端代码。这个形态为什么关键? 因为它同时满足两件事: 对人, 兼顾灵活性和易用性, 几行脚本就能处理非标需求; 对 AI, 这正是它最擅长的工作对象--脚本短小、目标明确、写完当场就能验证对不对。让 AI 来写这些脚本, 整个流程就变成: 你用自然语言说需求, AI 生成脚本, 拿到平台里跑一遍验证, 结果不对就再说一遍、再改一版。对比一下传统路径--需求提给开发、排期、开发、测试、发版, 一次非标需求的落地从按周算变成按对话算。数据过滤、场景联动这些最常见的定制活儿, 都走这条路。

统一物模型: AI 能直接读懂设备。每台设备有什么属性、什么功能、什么事件, 在平台里是一份机器可读的标准定义。这件事对 AI 的意义很直接: AI 要帮人配设备、写脚本、查问题, 前提是它得知道"这台设备是什么、有哪些数据"。有了物模型, AI 不用去翻纸质点表和接口文档--那些是给人看的, 机器读不懂; 它直接读物模型, 一读就知道温度在哪、控制指令怎么下发。

设备文档自动解析: 从说明书到物模型。接设备最费工的环节, 是照着厂商给的点表逐条配物模型--几百个点, 一个一个录。而设备说明书、点表 Excel、通信协议 PDF 这些文档, 本来就是结构化的信息, 只是给人看的。AI 自动识别这些文档、解析成物模型和相关数据配置, 逐条录入就变成了交一份文档的事, 设备接入里最重的人工环节直接卸掉。

内嵌数据管道: 持续产出干净的数据。从设备到存储, 采集、过滤、解析、入库每个环节都在平台内, 全程受控、可编程。智能告警、预测性维护这类 AI 应用, 效果好坏取决于数据质量--断断续续、缺上下文的原始数据喂不出可靠的模型。平台的数据管道把数据洗练成持续、干净、带设备上下文的形态, AI 应用接上来就能用, 不用先花半年做数据治理。

智能告警、预测性维护、自然语言配置设备、设备文档自动解析这些 AI 应用是平台的演进方向; 承接它们的底座, 现在就是现成的。

都有哪些行业在用 ​

平台已有两百多家客户, 以下是一部分, 按工业物联网链条上的角色分类:

  • 制造业工厂 - 福建某汽车空调配件制造商采购平台, 用于车间设备的数据采集与监控
  • 电力与环保设备商 - 某大型电气装备集团基于平台开展 IEC104 电力远动项目, 变电站(IEC61850)场景同样有采购落地; 南京某火电环保设备商(烟气治理、超低排放监测方向)采购平台做设备智能化研发
  • 工厂数字化软件商 - 湖南某 MES/ERP/WMS 解决方案商多次采购平台, 把平台用于自己工厂数字化项目里的设备数据环节
  • IT 服务与软件研发公司 - 南京某成立 20 余年的老牌系统集成商、成都某双软认定软件厂商, 以及山东、河南、河北、浙江、上海等地的软件公司
  • 智慧园区建设方 - 沈阳某智能化工程公司(有产业园区弱电智能化工程业绩)用平台做智慧园区项目的设备接入与监控
  • 高校科研 - 山东某高校采购平台用于科研与教学场景

客户结构说明了一件事: 平台承接的是"设备数据这一层"--制造厂直接用它采数据, MES厂商、集成商、软件商把它嵌进自己的方案里做采集底座, 各自专注自己擅长的那层。核心框架开源、采购即得源码, 一套平台在多个项目间复用, 这正是"开发平台"定位的直接体现。

适合谁用 ​

  • 工厂 - 想把设备数据采上来、异常第一时间找到人, 不想为此养一个开发团队
  • 技术团队 - 用平台接管设备接入、采集这些重复建设, 精力放在业务系统; 非标需求有脚本引擎和驱动扩展点
  • 系统集成商 - 一套平台复用到多个项目, 交付周期和风险都可控

和自己开发比, 差别在哪 ​

自己开发aiots 的做法
每种协议写一套驱动17 种工业协议驱动内置, 配置即接入
加采集点改代码、发版物模型加属性, 页面配置
告警、报表、大屏逐个造告警体系、数据中心、组态大屏现成
管理端、App 两套开发物模型定义一次, 多端共用
非标逻辑改后端、等排期脚本引擎三道关卡, 页面写完即生效
数据孤岛, 上层系统取数难开放平台 + MQTT 转发标准接口

了解更多 ​