# 当前 AIOT 项目组与 JetLinks Community 功能对比

## 1. 对比目标

本文重点从“物联网管理平台功能”角度，对比当前 AIOT 项目组与 JetLinks Community。

对比对象：

- 当前项目组：`aiot-admin`、`aiot-access`、`aiot-core`、`aiot-dao`、`aiot-datac`、`aiot-task`
- JetLinks Community：<https://github.com/jetlinks/jetlinks-community>

本文不重点讨论底层技术架构，只关注平台能力、业务功能和产品完整度。

## 2. 总体结论

当前 AIOT 项目组已经覆盖物联网管理平台的主要功能，包括：

- 产品管理
- 设备管理
- 物模型管理
- 设备接入
- MQTT/HTTP 接入
- 设备数据采集
- TDengine 时序数据
- 告警规则
- 设备联动
- 编解码管理
- GIS 管理
- 工单管理
- 平台级联
- 数据共享

JetLinks Community 的功能覆盖面更偏“通用物联网平台底座”，在以下方面更完整：

- 多协议统一接入
- 协议插件化
- 网络组件管理
- 规则引擎平台化
- 通知组件
- 数据可视化
- 权限体系
- 日志体系
- 设备模拟器
- 通用平台扩展能力

因此：

- 当前项目更像面向具体业务场景落地的 AIOT 管理平台。
- JetLinks 更像可二次开发的通用物联网基础平台。

## 3. 功能总览对比

| 功能域 | 当前 AIOT 项目组 | JetLinks Community | 对比结论 |
|---|---|---|---|
| 产品管理 | 支持产品、产品功能、产品主题、产品分类等 | 支持产品、物模型、协议绑定等 | 两者均具备，JetLinks 抽象更通用 |
| 设备管理 | 支持设备、分组、类型、分类、图片、认证等 | 支持设备生命周期、状态、配置、实例管理 | 两者均具备，当前项目业务页面更直接 |
| 物模型 | 支持 schema、功能、事件、属性等能力 | 支持 Thing Model，模型体系更标准化 | JetLinks 物模型体系更平台化 |
| 设备接入 | 支持 MQTT、HTTP、OneNET、AEP 等 | 支持 MQTT、TCP、UDP、HTTP、CoAP 等 | JetLinks 协议接入覆盖更广 |
| 网络组件 | 有网络配置和 MQTT/HTTP 客户端能力 | 有独立 network-component | JetLinks 网络层抽象更完整 |
| 协议/编解码 | 有编解码管理、解析相关能力 | 有 protocol-component、脚本、协议包机制 | JetLinks 更适合多协议扩展 |
| 数据采集 | 有 `aiot-datac`、采集任务、MQTT 数据处理 | 有网关、消息流、时序组件 | 两者均具备，JetLinks 更偏平台化数据管道 |
| 时序数据 | 支持 TDengine/TSDB | 支持 TimescaleDB、TDengine、ES 等 | JetLinks 存储适配更丰富 |
| 告警管理 | 有告警规则、告警记录、告警通知 | 通过规则引擎、通知组件实现 | 当前项目告警业务更直接，JetLinks 扩展更强 |
| 设备联动 | 有设备联动、条件、动作、日志 | 通过规则引擎和场景规则实现 | JetLinks 规则编排能力更完整 |
| 工单管理 | 有工单、工单流程、推送配置 | 社区版核心不以工单为主 | 当前项目工单能力更贴近业务应用 |
| GIS 管理 | 有 GIS 应用、图层、图例、轮廓 | JetLinks 核心不突出 GIS | 当前项目 GIS 业务能力更明显 |
| 平台级联 | 有平台级联、订阅、审计等页面 | 可通过集成/网关扩展实现 | 当前项目已有明确业务页面 |
| 数据共享 | 有 MQTT/HTTP 数据共享处理 | 可通过规则、网关、消息订阅扩展 | 当前项目数据共享更业务化 |
| 数据可视化 | 有 dashboard、设备概览、图表组件 | 有 dashboard/visualization-manager | JetLinks 可视化平台化更强 |
| 用户权限 | 依赖内部 MINS/IBLS/Token 体系 | 有 authentication-manager | JetLinks 权限模块开源完整度更高 |
| 日志审计 | 当前项目中不作为突出模块 | 有 logging-component/manager | JetLinks 日志体系更完整 |
| 通知能力 | 有告警通知、通知相关核心能力 | 有 notify-component，短信、邮件等通知抽象 | JetLinks 通知组件更通用 |
| 设备模拟 | 有设备模拟相关页面 | 有 simulator 模块 | JetLinks 设备模拟能力更独立 |
| 运维监控 | 有 MQTT 监控、平台监控相关页面 | 有日志、网关、设备状态等监控能力 | 两者均具备，侧重点不同 |

## 4. 产品与物模型管理

### 4.1 当前项目能力

当前项目围绕产品、设备类型、设备分类、设备模型、设备功能等组织平台能力。

相关功能页面包括：

- `deviceTypeManage`：设备类型管理
- `deviceCateManage`：设备分类管理
- `deviceModelManage`：设备模型管理
- `deviceFunManage`：设备功能管理
- `deviceAccess`：设备接入配置
- `coderDecoderManage`：编解码管理

相关后端能力包括：

- `IotProductController`
- `IotProductFeatureController`
- `IotFeatureController`
- `IotCategoryController`
- `IotCodecController`
- `IotCodecFieldController`
- `aiot-core/schema`
- `aiot-core/codec`

### 4.2 JetLinks 能力

JetLinks 以产品、设备、物模型、协议为核心组织管理能力。

典型能力包括：

- 产品定义
- 物模型定义
- 属性、事件、功能定义
- 产品与协议绑定
- 产品与设备实例关联
- 物模型数据处理

### 4.3 对比结论

| 方面 | 当前项目 | JetLinks |
|---|---|---|
| 产品管理 | 已具备业务化管理页面 | 更标准化、平台化 |
| 物模型 | 已有 schema 和功能模型 | Thing Model 体系更成熟 |
| 编解码 | 有专门编解码管理 | 协议包/脚本化能力更强 |
| 适合场景 | 固定业务场景快速落地 | 多行业、多协议平台化扩展 |

## 5. 设备管理

### 5.1 当前项目能力

当前项目设备管理相关功能比较完整，覆盖设备基础信息、分组、认证、图片、订阅、模拟等。

相关页面包括：

- `deviceManage`：设备管理
- `deviceGroupManage`：设备分组
- `deviceAuthManage`：设备认证
- `deviceSub`：设备订阅
- `deviceSubscribe`：设备订阅管理
- `deviceImitate`：设备模拟
- `deviceView`：设备视图
- `deviceOverview` / `deviceOverviewNew`：设备概览

相关后端能力包括：

- `IotDerviceController`
- `IotDeviceGroupController`
- `IotDerviceDataController`
- `IotDerviceEventController`
- `IotDerviceCmdController`
- `IotDervicePicController`
- `IotDeviceStatisticsController`

### 5.2 JetLinks 能力

JetLinks 设备管理能力更偏平台标准化，通常包括：

- 设备实例管理
- 设备状态管理
- 设备属性、事件、功能调用
- 设备分组/标签/关系
- 设备消息上下行
- 设备影子/配置
- 设备生命周期管理

### 5.3 对比结论

当前项目设备管理页面更贴合现有业务；JetLinks 设备模型更通用，适合大规模、多协议、多产品线设备统一管理。

## 6. 设备接入与协议管理

### 6.1 当前项目能力

当前项目设备接入主要由 `aiot-access` 和 `aiot-core` 承担。

已观察到的能力包括：

- MQTT 接入
- HTTP 接入
- OneNET 接入
- AEP 接入
- 网络配置
- 数据共享
- MQTT 消息服务
- 设备缓存
- 自定义 Topic

相关目录：

```text
aiot-access/aiot-access-server/src/main/java/com/aifa/mins/aiot/access/core/network
aiot-access/aiot-access-server/src/main/java/com/aifa/mins/aiot/access/mqtt
aiot-access/aiot-access-server/src/main/java/com/aifa/mins/aiot/access/datashare
aiot-core/src/main/java/com/aifa/mins/aiot/core/mqtt
aiot-core/src/main/java/com/aifa/mins/aiot/core/emq
```

### 6.2 JetLinks 能力

JetLinks 在设备接入方面是核心优势之一，支持：

- MQTT
- TCP
- UDP
- HTTP
- CoAP
- TLS/DTLS
- 网关接入
- 协议插件
- 网络组件管理
- 设备消息统一转换

### 6.3 对比结论

| 方面 | 当前项目 | JetLinks |
|---|---|---|
| MQTT | 支持 | 支持 |
| HTTP | 支持 | 支持 |
| TCP/UDP | 未作为明显功能暴露 | 支持 |
| CoAP | 未作为明显功能暴露 | 支持 |
| 第三方平台接入 | OneNET、AEP 更明确 | 可通过协议/网关扩展 |
| 协议插件化 | 有编解码能力，但插件化程度有限 | 更成熟 |
| 网络组件管理 | 有网络配置 | 独立 network-component |

如果当前平台后续需要接入更多厂家、更多私有协议，JetLinks 的协议与网络组件设计值得重点参考。

## 7. 数据采集与时序数据

### 7.1 当前项目能力

当前项目的数据相关能力主要包括：

- MQTT 数据接收
- 数据采集任务
- 数据转换处理
- TDengine/TAOS 数据存储
- 设备数据查询
- 事件数据管理

相关模块：

- `aiot-datac`
- `aiot-core/tsdb`
- `aiot-admin` 中的设备数据、事件数据、TDengine 查询页面

相关页面包括：

- `eventData`
- `deviceOverview`
- `deviceOverviewNew`
- `plfmMonitor`

### 7.2 JetLinks 能力

JetLinks 在数据处理上提供更平台化的能力：

- 设备消息统一处理
- 属性、事件、功能调用数据处理
- 时序数据组件
- TDengine 集成
- TimescaleDB 支持
- Elasticsearch 可选支持
- 数据可视化组件

### 7.3 对比结论

当前项目已经能支撑业务场景下的数据采集和 TDengine 存储；JetLinks 的优势在于数据模型更统一，时序数据存储适配更开放。

## 8. 告警与规则联动

### 8.1 当前项目能力

当前项目告警和联动相关功能比较明确。

相关页面包括：

- `warnRuleManage`：告警规则管理
- `deviceWarn`：设备告警
- `deviceLinkage`：设备联动

相关后端能力包括：

- `IotWarmRuleController`
- `IotWarmRecordController`
- `IotWarmNoticeController`
- `IotWarmSettingController`
- `IotDeviceLinkageController`
- `IotDeviceLinkageConditionController`
- `IotDeviceLinkageActionController`
- `IotDeviceLinkageActionLogController`
- `aiot-core/rule`
- `aiot-core/warn`

### 8.2 JetLinks 能力

JetLinks 将规则引擎作为核心能力，通常可覆盖：

- 设备数据触发
- 条件判断
- 场景联动
- 告警触发
- 通知发送
- 数据转发
- 脚本处理
- 规则执行日志

### 8.3 对比结论

当前项目已经有完整的告警和设备联动业务闭环，适合直接支撑具体业务。

JetLinks 的规则引擎更通用，适合把告警、联动、数据转发、消息处理统一成规则编排平台。

建议当前项目重点借鉴 JetLinks 的：

- 规则模型抽象
- 触发器设计
- 条件表达式设计
- 动作执行器设计
- 规则执行日志
- 通知组件解耦

## 9. 工单、GIS 与行业业务能力

### 9.1 当前项目能力

当前项目明显包含一些行业业务功能：

- 工单管理
- GIS 应用管理
- GIS 图层管理
- GIS 图例管理
- GIS 轮廓管理
- 平台级联
- 审核订阅

相关页面包括：

- `workOrder`
- `GISApplication`
- `GisAppManage`
- `GisLayerManage`
- `GisLegendManage`
- `GisOutlineManage`
- `platformCascade`
- `subAuditManage`

相关后端能力包括：

- `IotWorkOrderController`
- `IotWorkOrderProcessController`
- `GisAppController`
- `GisLayerController`
- `GisLegendController`
- `GisOutlineController`
- `IotPlatformCascadeController`
- `IotPlatformRssController`

### 9.2 JetLinks 能力

JetLinks Community 更偏通用物联网平台底座，核心关注：

- 设备接入
- 设备管理
- 规则引擎
- 数据处理
- 通知
- 可视化
- 权限
- 日志

工单、GIS、行业流程并不是 JetLinks 社区版最核心的功能重点，通常需要在业务层二次开发。

### 9.3 对比结论

在行业业务管理方面，当前项目比 JetLinks Community 更贴近具体业务落地。

如果当前项目已经服务于某个行业场景，如园区、城市、能源、设备运维等，保留当前业务层更合理。

## 10. 运维监控与平台管理

### 10.1 当前项目能力

当前项目已有一些平台运维和监控功能：

- MQTT 监控
- 平台监控
- 设备统计
- 设备概览
- 数据采集任务
- 任务调度
- 系统管理页面

相关页面包括：

- `plfmMonitor`
- `deviceOverview`
- `deviceOverviewNew`
- `dashboard`
- `system`

相关后端能力包括：

- `IotMonitorController`
- `IotMqttMonitorApi`
- `IotTdMqMonitorController`
- `IotDeviceStatisticsController`

### 10.2 JetLinks 能力

JetLinks 平台管理能力包括：

- 网关状态
- 设备状态
- 日志管理
- 通知配置
- 规则执行监控
- 数据看板
- 用户权限
- 系统配置

### 10.3 对比结论

当前项目偏业务运维视角，JetLinks 偏平台运维视角。

如果要增强当前项目，可以考虑补充：

- 接入网关运行状态
- 协议实例状态
- 规则执行链路
- 设备消息链路追踪
- 设备上下线日志
- 指令下发日志
- 数据转发日志

## 11. 功能成熟度评估

| 功能 | 当前项目成熟度 | JetLinks 成熟度 | 说明 |
|---|---:|---:|---|
| 设备管理 | 高 | 高 | 两者均完整 |
| 产品/物模型 | 中高 | 高 | JetLinks 标准化更强 |
| MQTT 接入 | 高 | 高 | 两者均支持 |
| HTTP 接入 | 中高 | 高 | JetLinks 接入抽象更统一 |
| TCP/UDP/CoAP | 低/未明显体现 | 高 | JetLinks 覆盖更广 |
| 编解码 | 中高 | 高 | JetLinks 协议包机制更强 |
| 告警规则 | 高 | 高 | 当前业务闭环更直接 |
| 规则引擎 | 中 | 高 | JetLinks 更平台化 |
| TDengine | 高 | 中高 | 当前项目绑定更明显 |
| 多时序存储 | 中 | 高 | JetLinks 适配更多 |
| GIS | 高 | 低/需二开 | 当前项目优势 |
| 工单 | 高 | 低/需二开 | 当前项目优势 |
| 平台级联 | 中高 | 中/需扩展 | 当前项目已有业务页面 |
| 数据可视化 | 中 | 中高 | JetLinks visualization-manager 更平台化 |
| 权限管理 | 中/依赖内部体系 | 高 | JetLinks 开源体系更完整 |
| 日志审计 | 中 | 高 | JetLinks 日志模块更突出 |

## 12. 当前项目优势

当前 AIOT 项目组的优势主要在业务落地能力：

1. 已有完整管理端页面。
2. 已有具体行业功能，如 GIS、工单、平台级联。
3. 已有设备接入、设备管理、告警、联动闭环。
4. 已接入 TDengine，适合已有数据存储方案。
5. 已有 OneNET、AEP 等第三方平台接入能力。
6. 与内部 MINS、权限、组织、门户等体系集成较深。

## 13. JetLinks 优势

JetLinks Community 的优势主要在平台底座能力：

1. 多协议接入能力更全面。
2. 网络组件、协议组件、网关组件抽象更清晰。
3. 物模型和设备消息体系更标准化。
4. 规则引擎更通用，可承载告警、联动、转发等场景。
5. 通知、日志、可视化、权限等通用平台能力更完整。
6. 开源生态更适合参考、二开和长期演进。

## 14. 建议借鉴方向

如果目标是提升当前物联网管理平台功能，建议优先从以下方向借鉴 JetLinks：

### 14.1 强化设备接入中心

建议将接入能力统一抽象为：

- 网络组件
- 协议组件
- 接入网关
- 设备消息转换
- 连接状态管理
- 上下行日志

### 14.2 强化协议和编解码管理

建议补充或优化：

- 协议包管理
- 脚本化解析
- 设备型号与协议绑定
- Topic 与物模型映射
- 上下行消息标准格式

### 14.3 强化规则引擎

建议将现有告警和联动统一抽象：

- 触发源：设备属性、事件、状态、定时任务
- 条件：表达式、阈值、时间窗口、组合条件
- 动作：通知、指令下发、数据转发、工单创建、HTTP/MQTT 推送
- 日志：执行记录、失败原因、重试记录

### 14.4 强化设备数据中心

建议形成统一设备数据视图：

- 最新属性
- 历史属性
- 事件记录
- 指令记录
- 上下线记录
- 告警记录
- 原始报文
- 解析后报文

### 14.5 强化平台运维能力

建议补充：

- 接入服务状态
- MQTT Broker 状态
- 协议实例状态
- 设备连接数
- 消息吞吐量
- 规则执行统计
- 数据入库失败统计
- 设备离线原因分析

## 15. 迁移或融合建议

不建议直接用 JetLinks 替换当前项目。

更稳妥的方式是：

1. 保留当前业务管理端、GIS、工单、平台级联等业务功能。
2. 重点参考 JetLinks 改造接入层、协议层、规则引擎和数据中心。
3. 如果需要引入 JetLinks，可将 JetLinks 作为设备接入和规则引擎底座，通过 API 与当前管理端集成。
4. 当前项目继续承载行业业务和内部系统集成。

推荐融合形态：

```text
当前 AIOT 管理端
  ├── 设备管理/业务页面/GIS/工单/平台级联
  ├── 对接内部权限、组织、门户
  └── 调用统一物联网底座 API
              |
              v
物联网底座能力
  ├── 设备接入
  ├── 协议解析
  ├── 物模型
  ├── 规则引擎
  ├── 时序数据
  └── 消息转发
```

## 16. 后续建议文档

建议继续补充以下专题文档：

1. 当前项目设备管理功能清单
2. 当前项目物模型与 JetLinks Thing Model 对比
3. 当前项目设备接入流程与 JetLinks Gateway 对比
4. 当前项目告警/联动与 JetLinks 规则引擎对比
5. 当前项目 TDengine 数据模型说明
6. 当前项目 GIS、工单、平台级联业务能力说明