

前面的文章解决了“多协议怎么接”“云平台怎么管”。
但智慧档案馆最尴尬的场景是:平台大屏很炫,网络一断,库房就瞎。
档案库房不能接受“云控依赖”:
因此,边缘端必须内置一套“轻量级规则引擎”,在网络断开时,依然能:
读传感器 → 算 PID → 控恒湿机 → 防震荡 → 防结露 → 记日志 → 等网络恢复再上报。
本文聚焦:如何在信创边缘网关(ARM/龙芯 + 麒麟/统信)上,用最小资源实现一套稳定、可审计、可同步的本地规则引擎。
功能 | 云平台 | 边缘规则引擎 |
|---|---|---|
目标设定 | ✅ 按季节/区域下发目标湿度 | ✅ 缓存目标值,断网照用 |
策略编排 | ✅ 八防/十防联动规则 | ✅ 执行缓存的本地规则 |
复杂计算 | ✅ AI 预测、跨域关联 | ❌ |
实时闭环 | ❌(网络延迟大) | ✅ PID、回滞、设备保护 |
本地联动 | ❌ | ✅ 漏水关阀、火险联动 |
审计存储 | ✅ 长期归档 | ✅ 本地缓存,恢复后同步 |
核心思想:
云做“决策大脑”,边做“反射神经”。 大脑睡着,神经要让身体活下去。
[输入层]
传感器数据(温湿度/水浸/烟感/门禁)
├─ 数据清洗(去抖、滤波)
├─ 质量位打标(good/doubtful/invalid)
└─ 时间戳对齐(本地高精度时钟)
│
▼
[规则匹配层](轻量 Rete 变种)
规则加载 → 条件评估 → 动作触发
│
▼
[执行层]
├─ PID 控制(恒湿机)
├─ 设备保护(最小启停)
├─ 联动控制(关阀、停空调)
├─ 告警生成(本地缓存)
│
▼
[存储层]
├─ 时序数据(LevelDB / SQLite)
├─ 事件日志(追加写,顺序IO)
├─ 规则快照(当前生效规则)
│
▼
[同步层](网络恢复后)
增量上传 + 冲突消解 + 审计对齐边缘规则采用 JSON + DSL 混合 的方式,保证可读、可解析、可热加载。
{
"rule_id": "EDGE-MOIST-001",
"rule_name": "A3区湿度超标本地处置",
"version": "20260901",
"priority": 100,
"enabled": true,
"domain": "防潮",
"condition": {
"logic": "AND",
"items": [
{"metric": "humidity", "operator": ">", "value": 60},
{"metric": "humidity_quality", "operator": "==", "value": "good"},
{"metric": "device_status:DH-A3-01", "operator": "==", "value": "online"}
]
},
"actions": [
{
"type": "control_device",
"device": "DH-A3-01",
"command": "start_dehumidify",
"params": {"power": 80},
"verify": true,
"timeout": 5
},
{
"type": "log_event",
"level": "warning",
"message": "湿度超标,启动本地除湿"
}
],
"constraints": {
"min_run_time": 300,
"min_stop_time": 180,
"max_daily_runs": 48
},
"source": "cloud_sync",
"sync_time": "2026-09-01T10:00:00+08:00"
}为了性能,边缘不支持复杂脚本,只支持结构化条件:
condition ::= atomic_condition | composite_condition
atomic_condition ::= metric operator value
composite_condition ::= { "logic": "AND|OR", "items": [condition, ...] }
operator ::= ">" | ">=" | "<" | "<=" | "==" | "!=" | "between"示例:
{
"logic": "AND",
"items": [
{"metric": "humidity", "operator": ">", "value": 60},
{"metric": "temperature", "operator": "between", "min": 18, "max": 28}
]
}动作类型 | 说明 | 八防场景 |
|---|---|---|
control_device | 控制设备(启停、调速、设参) | 防潮、防高温 |
stop_device | 停止设备 | 防火、防水 |
send_alert | 生成本地告警 | 所有防护域 |
log_event | 记录事件日志 | 审计 |
set_variable | 设置临时变量 | 状态机 |
call_emergency | 调用紧急预案 | 防火、防水 |
边缘规则引擎最核心的任务:让恒湿机在断网时依然“稳”。
cloud_sync 标记 loop every 10 seconds:
humidity = read_sensor("humidity")
if humidity.quality != "good":
log("sensor doubtful, keep last action")
continue
error = humidity.value - target_humidity
delta = pid.compute(error)
if delta > 0: // 需要除湿
if can_start_device("DH-A3-01"):
start_dehumidify(power=min(delta, 100))
else: // 接近目标
if can_stop_device("DH-A3-01"):
stop_dehumidify()
log_event("pid_adjust", {error, delta, action})这些逻辑不依赖规则配置,而是硬编码在边缘引擎内核,防止规则配置错误导致设备损坏:
// 伪代码:设备保护内核逻辑
if (device == COMPRESSOR) {
if (runtime < MIN_RUNTIME) {
block_stop("最小运行时间保护");
return;
}
if (stoptime < MIN_STOPTIME) {
block_start("最小停机时间保护");
return;
}
}{
"rule_id": "EDGE-FIRE-001",
"priority": 1000,
"condition": {
"logic": "OR",
"items": [
{"metric": "smoke_density", "operator": ">", "value": 0.5},
{"metric": "temp_rate_of_rise", "operator": ">", "value": 3}
]
},
"actions": [
{"type": "stop_device", "device": "AC-A3-01"},
{"type": "stop_device", "device": "AHU"},
{"type": "open_valve", "valve": "smoke_valve"},
{"type": "unlock_door", "door": "emergency_exit"},
{"type": "log_event", "level": "critical", "message": "本地火险联动"}
]
}{
"rule_id": "EDGE-WATER-001",
"priority": 900,
"condition": {
"items": [
{"metric": "water_leak", "operator": "==", "value": 1}
]
},
"actions": [
{"type": "close_valve", "valve": "water_valve_A3"},
{"type": "start_device", "device": "drain_pump"},
{"type": "stop_device", "device": "DH-A3-01"},
{"type": "log_event", "level": "warning", "message": "本地漏水联动"}
]
}{
"rule_id": "EDGE-MOIST-001",
"priority": 500,
"condition": {
"items": [
{"metric": "humidity", "operator": ">", "value": 60}
]
},
"actions": [
{"type": "control_device", "device": "DH-A3-01", "command": "start_dehumidify"},
{"type": "log_event", "level": "info", "message": "本地湿度调控"}
]
}数据类型 | 存储引擎 | 保留周期 | 用途 |
|---|---|---|---|
时序数据 | LevelDB / InfluxDB Lite | 7–30 天 | 本地趋势、PID 计算 |
事件日志 | SQLite / WAL | 30–90 天 | 审计、故障排查 |
规则快照 | SQLite | 永久 | 断网恢复后规则校验 |
同步状态 | SQLite | 永久 | 云边一致性 |
{
"event_id": "EVT-20260918-143000-001",
"ts": "2026-09-18T14:30:00.123+08:00",
"rule_id": "EDGE-MOIST-001",
"rule_version": "20260901",
"trigger": {
"metric": "humidity",
"value": 61.2,
"threshold": 60
},
"action": {
"type": "control_device",
"device": "DH-A3-01",
"command": "start_dehumidify",
"params": {"power": 80},
"result": "success",
"verify_value": 1
},
"edge_status": "offline",
"sync_status": "pending"
}网络恢复
↓
边缘上报“断网时间段 + 规则版本”
↓
云平台比对规则版本
↓
版本一致 → 接收边缘数据,标记为 backfilled
版本不一致 → 下发最新规则,边缘重新计算(如有必要)
↓
云平台生成“断网期间合规报告”
↓
边缘清理已同步数据(保留审计日志)年检时,审计员看到:
结论:断网不是“数据黑洞”,而是“受控自治”。
资源 | 预算 | 说明 |
|---|---|---|
CPU | < 30% | 规则匹配 + PID 计算 |
内存 | < 100MB | 规则缓存 + 数据缓存 |
存储 | < 1GB/月 | 时序数据 + 日志 |
启动时间 | < 10s | 断网重启后快速接管 |
domain + priority 建立索引,快速匹配 边缘端规则引擎的本质,不是“在边缘跑一套小云平台”,而是:
用极简的 DSL 表达八防规则,用硬编码保护设备安全,用本地存储保证审计完整,用云边同步实现最终一致,最终让档案库房在网络断开时,依然“稳得住、控得准、说得清”。
当网络中断 48 小时,而库房湿度依然平稳、漏水及时处置、所有行为可追溯——这才是真正落地的边缘自治。
标签:#智慧档案馆建设 #档案温湿度监控系统 #档案库房温湿度 #档案八防 #档案十防 #恒湿机 #恒湿消毒净化一体机 #边缘计算 #规则引擎 #本地自治 #断网运行 #信创边缘网关、
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。