物联网 · 盛世宏博 · 智慧档案
智慧档案系统工程里最容易犯的错,是"平台把所有设备都当空调控制"。
恒湿机的本质是环境闭环:
安防设备的本质是事件产生器:
联动逻辑是单向的:安防事件 → 限制或改变恒湿机行为,但恒湿机永远不该反向控制安防设备。
恒湿机"因为湿度到了就关门"——这是工程事故,不是智能。
安防事件 | 恒湿机受影响 | 动作 | 恢复条件 |
|---|---|---|---|
门开 | 消杀模块 | UV/臭氧立即停止,保留净化 | 门关 + 延时30s |
有人 | 消杀模块 | 禁止UV/臭氧,保留等离子低功率 | 无人状态确认 |
消防/烟感 | 全部 | 停加湿、关进水阀、机组交消防托管 | 消防复位+人工确认 |
水浸 | 加湿/进水 | 关进水阀+开排水泵+红警 | 水浸解除+人工确认 |
红外入侵(布防) | 消杀/通风 | 可继续运行,平台升级告警 | 撤防或解除 |
紧急按钮 | 全部 | 紧急停机 | 人工复位 |
玻璃破碎 | 报警 | 联动视频弹窗+声光 | 人工确认 |
这是现场调试最痛的教训。
错误做法:
门禁控制器 → 网络 → 平台 → 判断有人 → 下发停消杀 → 恒湿机问题:
正确做法(三级联锁):
门磁干接点 ──┐
红外/微波 ───┤
烟感继电器 ───┼──▶ 恒湿机 DI 输入 ──▶ 硬件切断消杀/加湿输出
急停按钮 ────┘ (不依赖任何通讯)恒湿机内部:
门禁控制器 ──▶ 边缘网关 ──▶ 判断 ──▶ Modbus TCP/RS485 下发恒湿机平台 ──▶ 联动规则引擎 ──▶ 多设备协同门禁控制器:
门磁 NO/NC ──▶ 恒湿机 DI1(门开=1)
出门按钮 ──▶ 恒湿机 DI2(可选)
恒湿机:
DI1=1 → 硬件禁止 UV/臭氧输出
DI1=0 且 延时30s → 恢复允许(避免频繁启停)# 门禁事件处理
def on_door_event(zone, door_state, timestamp):
machine = get_humidifier(zone)
if door_state == "open":
# 立即停止强消杀
if machine.disinfect_mode in (UV, OZONE):
machine.emergency_stop_disinfect()
platform_alert(f"{zone}门开,消杀已紧急停止",
level="warning")
audit_log(zone, "door_open", "stop_disinfect", timestamp)
elif door_state == "closed":
# 延时恢复,避免人员刚进门又关门反复启停
delay(30s)
if not machine.has_human() and machine.auto_mode:
machine.resume_disinfect()改进:门禁+红外双确认有人;门磁状态优先于刷卡记录。
消防控制柜:
火警继电器无源触点 ──▶ 恒湿机 DI3(消防=1)
恒湿机内部:
消防=1 → 立即:
1. 停所有消杀(UV/臭氧/等离子)
2. 停加湿,关进水电磁阀
3. 除湿可继续(排湿有利)
4. 新风机切换消防模式(如接新风机)
5. 状态切"消防托管",不接受平台指令消防事件 ──▶ 平台:
├── 所有恒湿机消杀强制停止
├── 启动消防应急预案
├── 视频切换消防通道
├── 短信/电话通知值班人员
└── 记录:消防事件时间、设备停机时间、恢复时间某项目验收时,消防测试后恒湿机自动恢复运行——直接判不合格。消防复位后必须人工确认。
恒湿机加湿需要补水。水管破裂/浮球阀失效/排水堵 → 库房进水 → 档案报废。
水浸传感器(库房低点/加湿机底部):
正常 ──▶ 干接点断开
水浸 ──▶ 干接点闭合 ──▶ 恒湿机 DI4
恒湿机:
水浸=1 → 立即:
1. 停加湿
2. 关进水电磁阀(硬件继电器,不依赖通讯)
3. 开排水泵(如有)
4. 平台红警 + 短信 + 工单
恢复:
水浸解除 + 人工确认排水完成 → 才允许恢复加湿1. 手动触发门磁(磁铁远离开关)→ 恒湿机 DI 指示灯亮
2. 确认消杀立即停止(听继电器释放声)
3. 手动触发消防 → 确认加湿停机、进水阀关闭
4. 手动触发水浸 → 确认加湿停机、排水泵启动
5. 急停按钮 → 全部停机硬联锁不依赖网络和平台,断网也要测。
1. 门禁刷卡开门 → 网关收到事件 ≤200ms
2. 恒湿机消杀停止 ≤500ms
3. 关门 → 30s 后消杀恢复(如无人)
4. 平台断网 → 网关本地联动仍生效1. 门开 → 平台弹窗 + 视频切换 + 短信
2. 消防 → 全馆设备停机 + 应急预案启动
3. 水浸 → 红警 + 工单派发
4. 审计日志:事件时间、设备动作、操作人员完整1. 拔门禁网线 → 网关检测超时 → 恒湿机进入"安全模式"(禁止消杀)
2. 拔恒湿机网线 → 安防事件照常记录,恢复后补传
3. 平台宕机 → 网关/硬联锁独立工作
4. 网关断电 → 恒湿机硬联锁靠 DI 干接点仍然有效触发:门禁"门开" OR 红外"有人"
条件:消杀模式 IN (UV, 臭氧)
动作:
- 写 disinfect_mode = 0
- 平台告警"人员进入,消杀已停止"
- 视频弹窗
优先级:高(不等待确认)触发:消防=1
条件:任意
动作:
- 所有恒湿机停消杀
- 所有恒湿机关加湿、关进水
- 启动消防预案
- 短信值班人员
优先级:最高(可打断其他所有规则)
恢复:人工确认,不自动恢复触发:水浸=1
条件:任意
动作:
- 停加湿
- 关进水阀
- 开排水泵
- 红警 + 工单
恢复:水浸解除 + 人工确认触发:门禁"门关" AND 红外"无人"
延时:30s
条件:消杀模式 != 消防托管
动作:
- 恢复消杀模式
- 平台记录"消杀自动恢复"项目 | 标准 |
|---|---|
硬联锁响应 | <100ms(示波器测) |
网关联动响应 | <500ms |
平台联动响应 | <2s |
消防停机 | 100%有效,断网/断平台均有效 |
消防恢复 | 必须人工确认,不自动恢复 |
门禁消杀互锁 | 门开→消杀停,100%有效 |
水浸保护 | 停加湿+关进水,硬件继电器动作 |
断网测试 | 硬联锁+网关联动均正常 |
审计日志 | 事件/动作/时间/操作人完整可追溯 |
故障注入 | 5种故障场景全部通过 |
智慧档案系统里,恒湿机和安防设备的联动,核心是分层:
L1 硬联锁:门磁/消防/水浸/急停干接点直接进恒湿机 DI,硬件切断,毫秒级,不依赖任何软件。这是安全底线。
L2 网关逻辑:门禁/红外/烟感状态到网关,本地判断,断网照常。这是稳定保障。
L3 平台联动:多设备协同、视频弹窗、短信工单、审计追溯。这是管理增值。
三层各管一段,别把安全逻辑全放平台上,也别指望恒湿机自己懂安防。
安防是边界,恒湿是环境,联动是桥梁——桥断了,人不能掉下去。
关键词:智慧档案,恒湿机,安防联动,门禁互锁,消防联动,水浸保护,硬联锁,边缘网关,平台联动,审计追溯
标签:#智慧档案 #恒湿机 #安防联动 #门禁互锁 #消防联动 #水浸保护 #硬联锁 #边缘网关 #平台联动 #联动调试
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。