物联网监控与设备管理

制冷是监控回本最快的一个方向，因为工况被破坏时肉眼看不出来。夜里被顶开一条缝的门，到早上都不会有人注意到，而到那时结果已经替您定好了。

举个例子。 周五傍晚，冷冻库的压缩机坏了。一夜之间货品化冻，周六被部分二次冷冻，周一整批报损。有了监控，故障消息在周五 21:00 就到了，事情止于叫一次维修服务。

而且设备各不相同。冷冻柜和熟食冷藏柜，允许温度不同、越限速度不同、出错代价也不同。因此正常范围不是给全网设一个，而是按每一台来设——并考虑里面放的是什么。

一台制冷设备上能取到什么：

• 温度 — 按设定的测量频率取当前值，可取容积内一个或多个点
• 温度变化速度 — 不只是「现在是多少」，还有「变得有多快」：缓慢漂移和骤然跳变意味着不同的故障
• 开门 — 什么时候开的、什么时候关的、门敞开了多久
• 压缩机运行 — 在转还是停了、多久启动一次、每次运行多久
• 供电 — 设备上有没有电压，以及是在哪一刻断的
• 控制器报错 — 机组自己上报的故障码，前提是它的控制器能做到
• 是否在线 — 设备是按时上线，还是沉默超过了允许时长

具体能取哪些，取决于设备型号。如果原装控制器对外输出数值和错误码，系统就直接读取。如果不输出，就加装外置的温度、门磁和电源传感器。贵方设备上具体有哪些可用，在调研时按其文档确定，而不是事先承诺。

凡是设备无人常驻看管、故障要靠后果才被发现的地方，都需要这套系统。变的是读数的组合和出错的代价——系统的结构始终不变。

• 自动售货 — 远端网点上的售货机：机构状态、温度、支付模块、是否在线
• 微型市场 — 办公楼和企业里没有店员的陈列柜和冰柜
• 冷藏仓库 — 全天候运行、且需要证明存储条件的冷库和机组
• 普通仓库 — 库房内的温湿度、供电、各区域的出入、建筑设备系统的状态
• 商用设备 — 连锁门店卖场里的陈列柜、岛柜和柜体
• 环境系统 — 室内是否维持在设定温度、偏离了多少
• 通风 — 机组是否在运行、滤网堵到什么程度、累计运行了多少小时
• 空调 — 运行模式、启动频率、实际温度与设定温度的偏差
• 供暖 — 供水和回水温度、回路运行情况、故障状态
• 水泵 — 在转还是闲置、耗电多少、多久启动一次、累计运行多久
• 压缩机 — 运行模式、循环时长、累计运行时长、故障停机
• 电动机 — 电流消耗、运行时间、异常工况
• 生产装置 — 状态、停机、控制器报错、两次维护之间的运行小时数
• 工业设备 — 分布在一个或多个场地、来自不同厂商的设备群
• 供电设备 — 有没有电、参数如何、备用电源有没有投入
• 电子锁 — 开启、关闭、访问尝试、锁的状态
• 传感器 — 温度、湿度、压力、电流，以及现场其他可测量的量值

面板用账号密码在浏览器里打开——就像一个普通网站。无需安装任何东西，手机上也能用。

第一屏。 顶部是计数：现在有多少台设备在线、多少台沉默、此刻有多少条未结异常。下面是场地清单，每个场地下挂着它的设备，每台设备都有一个彩色状态（正常、提醒、故障、离线）和当前数值。

设备卡片 点击任何一台设备即可打开。它汇总了关于这台冰柜或机组的一切：

• 当前读数 — 此刻的温度、门、供电、压缩机运行情况
• 一段时间的曲线 — 读数在一天、一周或一个月里怎么变的；线上标出了开门、压缩机启动和断电
• 事件日志 — 这台设备上的全部异常：什么时候发生、发给了谁、谁接手的、怎么关闭的
• 错误日志 — 控制器上报过的错误码，附含义解释和重复出现的历史
• 测量历史 — 保存期内的全部测量值，不做抽稀，可导出为文件
• 铭牌与维护 — 型号、安装日期，以及对这台设备做过什么、什么时候做的
• 操控 — 设定温度和运行模式（前提是设备控制器接受指令）；每一次修改都连同操作者和结果写入日志

设置只需做一次 此后就自行运转：按设备类型设定的正常范围和保持时长；按场地、事件类型和时段设定的责任人与消息下发规则；员工角色——谁能看到什么、能做什么；按场地、地区和设备类型划分的分组与筛选。

为什么要保存历史。 它就是全部测量值和全部事件，连同精确时间一并保存，随时可以调取。它有五个用处：

• 事后复盘某个案例 — 周五夜里冷库发生了什么，可以精确到分钟去看，而不是靠当班的人回忆
• 证明存储工况 — 一段时间的曲线可以导出为文件，拿给检查方或合作连锁看
• 与维修方按事实讲道理 — 维修之后机组又进了几次故障，在日志里一目了然
• 安排维护 — 按实际运行小时数和启动次数，而不是按计划表上的日期
• 发现磨损 — 把同一台设备半年前的运行情况和现在作对比

关于曲线还要单说一句：它们是为复盘用的，不是为报表用的。当温度线上同时标出了开门、压缩机启动和断电，异常的原因一眼就读出来了——不必再去比对四个不同的屏幕。

系统的主要工作建立在简单规则之上：某个数值持续超过多少分钟 = 向某个人发某条消息。这已经足以覆盖突发状况，任何一次落地也都从这里开始。

当历史积累了几个月，就可以在它之上再加一层数据分析。它找的不是越限，而是某一台设备惯常行为的变化。

举个例子。 压缩机平时八分钟就能进入工作状态。最近三周它需要十二分钟。没有任何一条界限被突破，按规则一条消息都不会发出——但这台机组显然正在走向故障，最好赶在它周末罢工之前把它维护掉。

• 积累的历史 — 每台设备长时间段内的读数和事件，包括维修和更换的记录
• 分析 — 某项读数平时是怎么表现的、运行时长是怎么增长的、同型设备彼此有什么差别
• 寻找与惯常的偏离 — 循环变长了、进入工作状态的时间变长了、电流消耗不寻常
• 故障预测的可能性 — 在积累了故障历史之后，就可以提前评估故障概率，并在停机之前安排维修

边界我们直说。 故障预测是在数据积累之后才成为可能的东西，而不是第一天就能用的功能。它需要的历史不只是读数，还包括故障本身：没有真实案例，模型就无从训练。因此在项目里它是数据采集运行一段时间之后的一个独立阶段，而不是首个版本里的一条。

相邻的方向是 把人工智能引入 业务流程，在那里同样的思路被用在订单、咨询和文档的数据上。