平台定位
IoT DC3 是一个开源、面向 AI 场景演进的分布式物联网平台，覆盖设备接入、数据采集、运营管理与智能分析。它把"设备接入"和"AI 运营"两件事连成一条闭环：先用多协议驱动把异构设备的数据采上来、归一成带语义的位号值，再让大模型读取这些数据并反向下发命令到设备。读完这页，你会知道它解决什么问题、给谁用、以及它和常见 IoT 平台到底差在哪。
它解决的两个缺口
大多数工业现场都卡在两处：
- 数据出不来，AI 用不上。 设备数据散落在各种协议和寄存器里，格式各异、缺少语义，AI 拿到也无从消费。
- AI 只能看，不能动。 即便接入了分析或大模型，通常也只能"观察"，无法把决策落到设备执行，闭环断在最后一步。
传统 IoT 平台往往只解决其一：要么强在设备连接，要么强在数据分析，少有把"采集—归一—分析—执行—反馈"打通成闭环的。IoT DC3 的设计目标正是补上这两个缺口。
一个闭环：从设备数据到 AI 执行
把上面的目标拆成可运行的链路，就是 IoT DC3 的核心工作方式：驱动采集 → 数据中心归一存储 → 大模型读取分析 → 通过工具调用下发命令 → 设备执行并回执。
闭环的关键在于：位号值不是裸数据，而是带语义标签、单位、时间戳和租户上下文的结构化 PointValue；大模型通过 Spring AI 的原生 @Tool 调用平台 API，既能查也能写，且每一步都受权限与确认机制约束（见 Agentic 中心）。
给谁用
- 需要把多类工业协议设备统一接入、集中管理的物联网平台搭建者；
- 做产线监控、设备健康、预测性维护的智能工厂/设备团队；
- 能源、农业、城市基础设施等远程监测与控制运营方；
- 习惯 Spring 生态、要在平台上做二次开发的后端开发者；
- 想探索"AI 辅助运营/智能体操作设备"的团队。
典型场景
| 场景 | 用 IoT DC3 做什么 |
|---|---|
| 智能工厂 | 产线监控、设备健康与预测性维护、OEE 统计 |
| 能源监测 | 远程抄表与计量、异常告警 |
| 智慧农业 | 大棚环境监测、灌溉控制、产量预测 |
| 智慧城市 | 路灯/环境/市政设施的监测与远程操作 |
能力支柱
- 多协议设备接入——28 个驱动覆盖工业现场总线、IoT 无线、数据库桥接、基础通信与仿真。
- AI 能力集成——基于 Spring AI 的智能体中心，大模型经 Tool-Calling 读写位号、执行命令、分析告警，兼容 GPT、Claude、DeepSeek、通义千问等主流模型，对话记忆持久化到数据库。
- 云原生微服务——Spring Boot 4 + Spring Cloud 2025，网关统一入口、gRPC 服务间通信、无状态可横向扩展。
- 实时数据引擎——驱动采集经 RabbitMQ 异步传输，时序存储支撑实时与历史查询，规则引擎驱动多级告警与通知，命令与事件全量历史可追溯。
- 多租户安全与隔离——JWT + Spring Security + RBAC，数据库/缓存/API 全链路租户隔离，支持 TLS 加密与审计。
- 开发者友好——Driver SDK 热插拔注册自定义驱动，前后端分离，Podman / Docker Compose 一键启动，提供 Kubernetes 部署路径。
与传统 IoT 平台的差异
IoT DC3 的差异点不是"支持多协议"——这一点很多平台都有。真正的组合优势在于：
- AI 原生集成：通过 Spring AI 内建，而非外挂一个独立分析服务；
- 协议广度：28 个驱动，含数据库桥接这类少见能力；
- 结构化 AI 输出：
PointValue带语义标签，便于模型直接消费； - 闭环命令执行：把 LLM 的决策落回设备执行；
- 全开源：没有专有内核；
- 多租户设计：隔离是地基而非补丁。
诚实的边界
"多协议"本身不构成差异化——它是入场券。IoT DC3 当前也不提供 RTSP/H.264 视频流接入这类能力；如果你的核心诉求是视频，需要另外评估。
技术栈一览
Java 21 · Spring Boot 4.0.6 · Spring Cloud 2025.1.1 · Spring AI 2.0.0· PostgreSQL（+ TimescaleDB / AGE / pgvector）· RabbitMQ · gRPC / Protobuf · MyBatis-Plus（Snowflake ID）。
系统全景
平台对外只暴露网关一个 HTTP 入口；四个中心各司其职，驱动在南向接入设备。下图是各角色的协作全景，逐层展开见 系统架构。