162 lines
8.3 KiB
Markdown
162 lines
8.3 KiB
Markdown
# 智能物联网管理系统 模块规划
|
||
|
||
---
|
||
|
||
## 1. 模块定位
|
||
|
||
智能物联网管理系统是整个智慧医养平台的 **IoT 设备基础设施管理层**，负责对全平台所有智能终端设备（智能呼叫终端、定位终端、健康监测设备、跌倒监测设备）进行统一注册、状态监控、数据接入、固件管理和告警处理。
|
||
|
||
本系统是底层技术中间件，不直接对终端用户提供功能界面，而是为安全系统（09）、健康管理（08）、家庭床位（15）等上层业务模块提供设备能力支撑。
|
||
|
||
---
|
||
|
||
## 2. 建设目标
|
||
|
||
1. 构建统一的 IoT 设备注册和台账管理体系，支持 4 类主要设备类型
|
||
2. 实现设备状态实时监控（在线/离线/低电量/故障）
|
||
3. 提供标准化的设备数据接入协议（MQTT/HTTP双模）
|
||
4. 支持批量设备管理（固件远程升级、批量配置下发）
|
||
5. 建立设备告警处理闭环（设备告警→业务系统→调度→处置）
|
||
|
||
---
|
||
|
||
## 3. 核心功能范围
|
||
|
||
### 3.1 一级模块
|
||
|
||
- 设备注册与台账
|
||
- 设备状态监控
|
||
- 数据接入层（MQTT/HTTP）
|
||
- 设备分组管理
|
||
- 固件管理
|
||
- 告警管理
|
||
- 数据API（供上层业务调用）
|
||
|
||
### 3.2 二级模块
|
||
|
||
- **设备注册**：4类设备（呼叫终端/定位终端/健康监测/跌倒监测）注册、SN码绑定老人
|
||
- **状态监控**：实时在线率、最近心跳时间、电量、信号强度、异常设备清单
|
||
- **MQTT接入**：设备端MQTT连接、Topic规范（设备状态/数据上报/指令下发）
|
||
- **设备分组**：按机构/区域/设备类型分组，支持批量操作
|
||
- **固件管理**：新固件包上传、兼容性校验、批量或定向远程升级
|
||
- **告警管理**：设备离线告警、低电量预警、故障上报、告警转业务系统
|
||
- **数据API**：历史数据查询、实时状态查询、设备列表过滤
|
||
|
||
### 3.3 核心功能说明
|
||
|
||
| 设备类型 | 主要功能 | 数据上报频率 | 告警触发条件 |
|
||
| ------------ | --------------------- | -------------- | ------------------- |
|
||
| 智能呼叫终端 | SOS按键、通话 | 心跳1次/5分钟 | SOS触发/离线>30分钟 |
|
||
| 定位终端 | GPS/LBS定位、运动轨迹 | 定位1次/5分钟 | 离开围栏/低电<20% |
|
||
| 健康监测 | 血压/心率/血氧 | 每次测量时 | 指标超阈值 |
|
||
| 跌倒监测 | 三轴加速度实时采集 | 跌倒事件触发时 | 跌倒检测阳性 |
|
||
|
||
---
|
||
|
||
## 4. 与现有 mall 的关系
|
||
|
||
**契合度：D（不适配）**
|
||
|
||
mall 是电商平台，完全不具备 IoT 基础设施能力：
|
||
|
||
| 能力需求 | mall 现状 | 结论 |
|
||
| -------------------------- | --------- | ---------- |
|
||
| MQTT Broker（IoT消息接入） | 无 | 须独立建设 |
|
||
| 设备注册与台账管理 | 无 | 须独立建设 |
|
||
| 设备固件OTA升级 | 无 | 须独立建设 |
|
||
| 时序数据存储与查询 | 无 | 须独立建设 |
|
||
| 设备状态实时监控仪表盘 | 无 | 须独立建设 |
|
||
|
||
mall 是通用电商平台，不具备任何 IoT 设备通信能力，强行堆入会导致架构崩溃。
|
||
|
||
---
|
||
|
||
## 5. 规划判断
|
||
|
||
**独立系统建设（IoT基础设施层）**
|
||
|
||
- MQTT Broker：EMQX（开源版或企业版）
|
||
- 设备管理平台：后端 Go/Java + Vue3 Web管理端
|
||
- 时序数据库：TimescaleDB（PostgreSQL扩展）
|
||
- 规则引擎：EMQX Rule Engine 或 自研告警规则服务
|
||
|
||
---
|
||
|
||
## 6. 需新增业务能力
|
||
|
||
1. **MQTT Broker 部署与配置**：高可用EMQX集群，支持TLS双向认证
|
||
2. **设备接入协议规范**：制定统一的MQTT Topic命名规范和数据格式（JSON Schema）
|
||
3. **设备认证体系**：每个设备预烧入证书，防止伪设备接入
|
||
4. **OTA固件升级**：分批次推送固件，支持升级失败自动回滚
|
||
5. **告警路由规则**：按告警类型和严重级别路由到对应业务系统（MQ）
|
||
6. **设备可视化地图**：GIS地图展示全部设备的地理分布和状态
|
||
|
||
---
|
||
|
||
## 7. 需新增数据模型
|
||
|
||
| 模型 | 关键字段 |
|
||
| ------------------- | ----------------------------------------------------------------------------------------------------------- |
|
||
| `iot_device` | id, device_type, device_sn, manufacturer, model, elder_id, org_id, status, firmware_version, last_heartbeat |
|
||
| `iot_device_cert` | device_id, cert_pem, private_key_hash, issued_at, expire_at |
|
||
| `iot_telemetry` | device_id, metric_type, value, reported_at（时序表） |
|
||
| `iot_alert` | id, device_id, alert_type, severity, payload(JSONB), received_at, routed_to, routed_at |
|
||
| `iot_firmware` | id, version, device_type, file_url, release_notes, compatible_models(array) |
|
||
| `iot_firmware_task` | id, firmware_id, target_device_ids(array), status, progress, started_at |
|
||
|
||
---
|
||
|
||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||
|
||
| 类别 | 技术选型 | 用途 |
|
||
| ----------- | ------------------ | ------------------------------- |
|
||
| MQTT Broker | EMQX（开源/企业） | IoT设备消息接入，支持百万级连接 |
|
||
| 时序数据库 | TimescaleDB | 设备上报的时序数据存储 |
|
||
| 消息队列 | Kafka | 设备告警事件的高吞吐处理 |
|
||
| GIS | 高德地图API | 设备分布地图 |
|
||
| OTA | 自研 + OSS文件存储 | 固件文件存储与下发 |
|
||
|
||
---
|
||
|
||
## 9. 外部系统对接关系
|
||
|
||
| 对接方 | 内容 | 方式 |
|
||
| ------------------ | -------------------------- | ------------- |
|
||
| 安全系统（09） | SOS/跌倒/定位数据输出 | Kafka消息消费 |
|
||
| 健康管理（08） | 健康监测数据输出 | Kafka消息消费 |
|
||
| 家庭床位（15） | 入户设备注册 | 内部注册API |
|
||
| 政府监管（01） | 设备在线率统计 | 内部统计API |
|
||
| 系统管理中心（05） | 设备接口型号注册（主数据） | 内部API |
|
||
| 技术中台（27） | API网关和服务注册 | 内部基础设施 |
|
||
|
||
---
|
||
|
||
## 10. 风险与边界
|
||
|
||
| 风险 | 说明 | 应对 |
|
||
| ------------------ | -------------------------------------------------- | ------------------------------------------ |
|
||
| 设备兼容性 | 不同厂商设备通信协议不统一 | 建立设备入网认证标准，要求厂商适配统一协议 |
|
||
| 高并发数据写入 | 大量设备同时上报数据时写入压力大 | 时序数据库 + 写入缓冲队列（Kafka） |
|
||
| MQTT安全 | 设备证书管理不当可能导致非授权接入 | TLS双向认证 + 设备证书轮换策略 |
|
||
| 边界：不含设备采购 | 本系统只负责软件接入管理，不负责设备硬件选型和采购 | 明确边界，由运营方制定设备白名单 |
|
||
|
||
---
|
||
|
||
## 11. 实施优先级与分期建议
|
||
|
||
**优先级：P2（但需在P1阶段完成基础框架，支撑安全系统SOS功能）**
|
||
|
||
| 分期 | 内容 | 前置条件 |
|
||
| -------- | ------------------------------------------------------ | ---------------- |
|
||
| P1配合 | MQTT Broker部署 + SOS设备接入（支撑呼叫中心+安全系统） | 基础设施部署完成 |
|
||
| P2第一期 | 设备注册台账 + 状态监控 + 告警路由 | — |
|
||
| P2第二期 | OTA固件升级 + 设备地图 + 时序数据查询API | — |
|
||
|
||
---
|
||
|
||
## 12. 结论
|
||
|
||
智能物联网管理系统是全平台 IoT 能力的基础设施层，mall 完全不具备此类能力，**必须独立建设**。
|
||
|
||
建议采用 EMQX 开源版本起步，视设备规模决定是否升级为企业版。MQTT Broker 的部署应在 P1 阶段与安全系统（09）同步完成，以支撑 SOS 紧急响应的核心安全功能。
|