35c - AI 辅助 IoT 系统架构

┌─────────────────────────────────────────────────────────────────┐
│                        ☁️ 云层 (Cloud Layer)                     │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────────┐   │
│  │ IoT 平台  │  │ 数据存储  │  │ AI/ML    │  │ 业务应用      │   │
│  │ AWS IoT  │  │ 时序数据库│  │ 模型训练  │  │ 仪表板/告警   │   │
│  │ Azure IoT│  │ InfluxDB │  │ SageMaker│  │ API 服务      │   │
│  └──────────┘  └──────────┘  └──────────┘  └──────────────┘   │
│                         ▲  MQTT/HTTPS/gRPC  ▲                   │
├─────────────────────────┼───────────────────┼───────────────────┤
│                    🔲 边缘层 (Edge Layer)                        │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────┐      │
│  │ 边缘网关      │  │ 边缘计算节点  │  │ 本地 MQTT Broker │      │
│  │ 协议转换      │  │ 数据预处理    │  │ 离线缓存         │      │
│  │ 数据聚合      │  │ AI 推理       │  │ 规则引擎         │      │
│  │ Greengrass   │  │ TinyML/Edge AI│  │ Mosquitto/NanoMQ│      │
│  └──────────────┘  └──────────────┘  └──────────────────┘      │
│                         ▲  MQTT/CoAP/BLE  ▲                     │
├─────────────────────────┼─────────────────┼─────────────────────┤
│                    📱 设备层 (Device Layer)                       │
│  ┌────────┐  ┌────────┐  ┌────────┐  ┌────────┐  ┌────────┐  │
│  │传感器   │  │执行器   │  │网关设备 │  │可穿戴   │  │工业设备 │  │
│  │ESP32   │  │STM32   │  │Pi/Jetson│  │nRF52   │  │PLC     │  │
│  │温湿度   │  │电机/阀门│  │数据汇聚 │  │BLE传感 │  │Modbus  │  │
│  └────────┘  └────────┘  └────────┘  └────────┘  └────────┘  │
└─────────────────────────────────────────────────────────────────┘

你是一位 IoT 系统架构师。为以下项目设计完整的 IoT 系统架构：

## 项目概述
- 应用场景：[智能家居/工业监控/农业/物流/...]
- 设备类型和数量：[列出设备类型和预估数量]
- 数据类型：[传感器数据/控制命令/视频流/...]
- 数据频率：[每秒/每分钟/事件驱动]

## 约束条件
- 网络环境：[Wi-Fi/蜂窝/LoRaWAN/卫星]
- 功耗要求：[电池供电/市电]
- 延迟要求：[实时 <100ms / 准实时 <1s / 非实时]
- 可靠性要求：[工业级/消费级]
- 预算范围：[设备成本/云服务月费]

## 请设计
1. 三层架构图（设备层→边缘层→云层）
2. 通信协议选择（MQTT/CoAP/HTTP/自定义）及理由
3. MQTT 主题层次设计
4. 边缘计算策略（哪些计算在边缘，哪些在云端）
5. 数据流设计（采集→传输→存储→处理→展示）
6. 安全架构（设备认证、数据加密、访问控制）
7. OTA 更新策略
8. 设备管理方案
9. 高可用和容灾设计
10. 成本估算

你是一位 MQTT 架构专家。为以下 IoT 系统设计 MQTT 主题层次：

## 系统信息
- 应用场景：[描述]
- 设备类型：[列出所有设备类型]
- 预估设备数量：[数量]
- 是否多租户：[是/否]
- 是否多区域：[是/否]

## 数据类型
1. 遥测数据：[列出传感器类型和数据格式]
2. 设备状态：[在线/离线/错误/...]
3. 控制命令：[列出可能的控制操作]
4. 配置更新：[列出可配置参数]
5. OTA 更新：[固件分发需求]
6. 告警事件：[列出告警类型]

## 请设计
1. 完整的主题层次结构（使用 / 分隔符）
2. 每个主题的用途、QoS 级别、保留消息策略
3. 通配符订阅模式（+ 和 #）
4. ACL 权限矩阵（哪些角色可以发布/订阅哪些主题）
5. 主题命名规范文档

## 设计原则
- 主题层次不超过 7 层
- 避免以 $ 开头（系统保留）
- 使用小写字母和连字符
- 支持未来扩展（新设备类型、新区域）

# MQTT 主题层次设计 - 智能建筑

## 主题结构
{org}/{site}/{building}/{floor}/{zone}/{device-type}/{device-id}/{data-type}

## 遥测数据（设备→云）
buildings/hq/main/3f/zone-a/sensor/temp-001/telemetry     # QoS 0
buildings/hq/main/3f/zone-a/sensor/humi-001/telemetry     # QoS 0
buildings/hq/main/3f/zone-a/meter/elec-001/telemetry      # QoS 1

## 设备状态（设备→云）
buildings/hq/main/3f/zone-a/sensor/temp-001/status        # QoS 1, Retained
buildings/hq/main/3f/zone-a/hvac/ac-001/status            # QoS 1, Retained

## 控制命令（云→设备）
buildings/hq/main/3f/zone-a/hvac/ac-001/command           # QoS 1
buildings/hq/main/3f/zone-a/light/led-001/command         # QoS 1

## 配置更新（云→设备）
buildings/hq/main/3f/zone-a/sensor/temp-001/config        # QoS 1, Retained

## OTA 更新
ota/{device-type}/{firmware-version}/binary               # QoS 1
ota/{device-type}/{device-id}/status                      # QoS 1

## 告警事件
alerts/buildings/hq/main/3f/zone-a/{device-type}/{device-id}  # QoS 1

## 通配符订阅模式
# 订阅某楼层所有传感器遥测
buildings/hq/main/3f/+/sensor/+/telemetry

# 订阅整栋楼所有告警
alerts/buildings/hq/main/#

# 订阅某设备类型的所有状态
buildings/hq/main/+/+/hvac/+/status

## ACL 权限矩阵
| 角色 | 发布权限 | 订阅权限 |
|------|---------|---------|
| 设备 | {自身路径}/telemetry, status | {自身路径}/command, config |
| 楼层管理 | .../command | {楼层}/#  |
| 运维 | ota/# | buildings/#, alerts/# |
| 仪表板 | 无 | buildings/#（只读） |

需要 MQTT Broker？
├── 设备数 < 1000，预算有限
│   └── Mosquitto（单节点，简单可靠）
├── 设备数 1000-10万，需要集群
│   ├── 已用 AWS → AWS IoT Core
│   ├── 已用 Azure → Azure IoT Hub
│   └── 自建 → EMQX 开源版
├── 设备数 > 10万，企业级
│   ├── 需要商业支持 → HiveMQ Enterprise / EMQX Enterprise
│   └── 开源自建 → EMQX 集群
└── 边缘部署（资源受限）
    └── NanoMQ 或 Mosquitto

你是一位 ESP-IDF MQTT 专家。为 ESP32 实现 MQTT 5.0 客户端：

## Broker 信息
- 地址：[broker 地址]
- 端口：[1883/8883(TLS)]
- 认证方式：[用户名密码/客户端证书/Token]

## 功能需求
1. 连接管理：自动重连（指数退避），遗嘱消息配置
2. 发布：遥测数据（QoS 0，每 [N] 秒），状态变更（QoS 1，事件驱动）
3. 订阅：控制命令（QoS 1），配置更新（QoS 1，Retained）
4. MQTT 5.0 特性：
   - 用户属性：附带设备型号和固件版本
   - 主题别名：高频主题使用别名减少带宽
   - 会话过期：[时间] 秒
5. 离线消息缓存：断连时缓存到 NVS，重连后发送

## 安全要求
- TLS 1.2/1.3（服务器证书验证）
- 客户端证书双向认证（如需要）
- 凭证存储在 NVS 加密分区

## 代码规范
- 使用 ESP-IDF 的 esp_mqtt_client 组件
- 事件驱动架构（MQTT 事件回调）
- JSON 格式消息体（使用 cJSON）
- 线程安全的发布接口

你是一位 MQTT 后端开发专家。用 Python 实现 MQTT 消息处理服务：

## 技术栈
- MQTT 客户端库：paho-mqtt 2.x（支持 MQTT 5.0）
- 消息处理：asyncio
- 数据存储：[InfluxDB/TimescaleDB/PostgreSQL]

## 功能需求
1. 订阅设备遥测主题（通配符）
2. 消息解析和验证（JSON Schema）
3. 数据写入时序数据库
4. 告警规则引擎（阈值检测、变化率检测）
5. 设备在线状态追踪（基于遗嘱消息和心跳）
6. 共享订阅实现负载均衡

## 非功能需求
- 处理能力：[N] 消息/秒
- 消息丢失率：< 0.01%
- 支持优雅关闭和重启

你是一位 CoAP/LwM2M 协议专家。为 [设备类型] 设计 CoAP 资源：

## 设备信息
- MCU：[型号]
- 网络：[6LoWPAN/Thread/Wi-Fi]
- CoAP 库：[libcoap/microcoap/Zephyr CoAP]

## 资源定义
请设计 CoAP 资源树：
1. 传感器数据资源（GET，Observable）
2. 执行器控制资源（PUT/POST）
3. 设备信息资源（GET）
4. 配置资源（GET/PUT）

## 要求
1. 使用 CBOR 编码（比 JSON 更紧凑）
2. 支持 Observe（服务器推送变更）
3. 支持 Block-wise 传输（大数据分块）
4. 资源发现（/.well-known/core）
5. DTLS 安全（PSK 或证书）

## 输出格式
- CoRE Link Format 资源描述
- 每个资源的 URI、方法、内容格式、观察支持

┌─────────────────────────────────────────────┐
│              远端云 (Cloud)                   │
│  大规模存储、模型训练、全局分析、业务逻辑      │
├─────────────────────────────────────────────┤
│           近端云 / CDN 边缘                   │
│  Lambda@Edge、CloudFront Functions           │
│  低延迟 API、内容分发                         │
├─────────────────────────────────────────────┤
│           本地边缘 (On-Premise Edge)          │
│  边缘服务器、工业 PC、Jetson                  │
│  AI 推理、视频分析、数据聚合                   │
├─────────────────────────────────────────────┤
│           微边缘 (Micro Edge)                 │
│  网关设备、Raspberry Pi                       │
│  协议转换、数据过滤、本地规则                  │
├─────────────────────────────────────────────┤
│           设备边缘 (Device Edge)              │
│  MCU 上的 TinyML                             │
│  传感器融合、异常检测、关键词识别              │
└─────────────────────────────────────────────┘

你是一位 TinyML 专家。为以下应用设计边缘 AI 方案：

## 应用需求
- 任务：[分类/检测/异常检测/回归]
- 输入数据：[传感器类型、采样率、数据维度]
- 输出：[类别数/异常分数/预测值]
- 精度要求：[准确率/F1 分数]
- 延迟要求：[推理时间上限]

## 硬件约束
- MCU：[型号]
- 可用 Flash：[数值] KB（用于模型存储）
- 可用 RAM：[数值] KB（用于推理缓冲）
- 是否有 DSP/FPU：[是/否]
- 是否有 AI 加速器：[是/否]

## 请设计
1. 模型架构推荐（CNN/RNN/Autoencoder/决策树）
2. 量化策略（INT8/INT16/混合精度）
3. 数据预处理流水线（在 MCU 上执行）
4. 模型大小和推理时间估算
5. 训练→量化→部署的完整工作流
6. 功耗影响评估

你是一位 IoT 边缘网关架构师。设计边缘网关方案：

## 网关硬件
- 平台：[Raspberry Pi 5 / Jetson Nano / 工业网关 / 自定义]
- 操作系统：[Linux / Yocto / Ubuntu Core]
- 网络接口：[以太网/Wi-Fi/4G-LTE/LoRaWAN]

## 下行设备
- 协议：[BLE/Zigbee/Z-Wave/Modbus/CAN/LoRa]
- 设备数量：[数量]
- 数据频率：[频率]

## 上行云端
- 协议：[MQTT/HTTPS/gRPC]
- Broker/平台：[AWS IoT Core/Azure IoT Hub/自建]

## 功能需求
1. 协议转换：[下行协议] → MQTT
2. 数据聚合：[聚合策略，如平均值/最大值/采样]
3. 本地规则引擎：[列出本地处理规则]
4. 离线缓存：断网时缓存数据，恢复后上传
5. 边缘 AI：[如需要，描述推理任务]
6. 设备管理：本地设备发现和配置
7. OTA 代理：接收云端固件，分发给下行设备

## 非功能需求
- 可靠性：[7×24 运行/可接受重启]
- 安全：[TLS/设备认证/防火墙]
- 远程管理：[SSH/VPN/云端管理]
- 容器化：[Docker/Podman/无]

你是一位边缘计算架构师。帮我选择合适的边缘计算平台：

## 项目需求
- 边缘节点数量：[数量]
- 边缘硬件：[型号列表]
- 需要的边缘能力：
  □ AI/ML 推理
  □ 容器化应用部署
  □ 协议转换
  □ 数据预处理
  □ 离线运行
  □ OTA 更新
  □ 远程管理

## 已有技术栈
- 云平台：[AWS/Azure/GCP/自建]
- 容器编排：[K8s/Docker Compose/无]
- CI/CD：[工具]

## 约束
- 团队规模：[人数]
- 运维能力：[高/中/低]
- 预算：[范围]

## 请对比推荐
1. 候选平台对比表
2. 推荐方案及理由
3. 部署架构图
4. 迁移路径（如从现有方案迁移）

┌─────────────────────────────────────────────┐
│              Flash 分区布局                    │
├─────────────────────────────────────────────┤
│  Bootloader（不可 OTA 更新）                  │
│  ├── 验证签名                                │
│  ├── 选择启动分区（A 或 B）                    │
│  └── 回滚逻辑                                │
├─────────────────────────────────────────────┤
│  OTA Data（分区选择标记）                      │
│  ├── 当前活动分区标记                          │
│  ├── 更新状态（pending/verified/aborted）      │
│  └── 启动计数器（用于回滚判断）                 │
├─────────────────────────────────────────────┤
│  分区 A（ota_0）                              │
│  └── 固件镜像 A（当前运行版本）                 │
├─────────────────────────────────────────────┤
│  分区 B（ota_1）                              │
│  └── 固件镜像 B（新版本写入此处）               │
├─────────────────────────────────────────────┤
│  NVS（非易失性存储）                           │
│  └── 配置数据、WiFi 凭证、设备证书              │
├─────────────────────────────────────────────┤
│  SPIFFS/LittleFS（文件系统）                   │
│  └── 日志、缓存数据、Web 资源                   │
└─────────────────────────────────────────────┘

设备                          OTA 服务器                    管理后台
 │                               │                           │
 │  1. 检查更新（版本号+设备信息）  │                           │
 │ ─────────────────────────────>│                           │
 │                               │                           │
 │  2. 返回更新信息（版本、大小、  │                           │
 │     校验和、下载 URL）         │                           │
 │ <─────────────────────────────│                           │
 │                               │                           │
 │  3. 下载固件（分块传输）        │                           │
 │ ─────────────────────────────>│                           │
 │ <─────────────────────────────│                           │
 │                               │                           │
 │  4. 验证固件（SHA-256 + 签名） │                           │
 │  [本地验证]                    │                           │
 │                               │                           │
 │  5. 写入非活动分区             │                           │
 │  [写入 ota_1]                 │                           │
 │                               │                           │
 │  6. 标记新分区为待验证          │                           │
 │  [设置 OTA Data]              │                           │
 │                               │                           │
 │  7. 重启，从新分区启动          │                           │
 │  [Bootloader 选择 ota_1]      │                           │
 │                               │                           │
 │  8. 自检通过，确认新固件        │                           │
 │  [标记为 verified]            │                           │
 │                               │                           │
 │  9. 上报更新结果               │                           │
 │ ─────────────────────────────>│ ────────────────────────> │
 │                               │                           │
 │  [如果自检失败]                │                           │
 │  8'. 回滚到旧分区              │                           │
 │  [Bootloader 选择 ota_0]      │                           │
 │  9'. 上报回滚事件              │                           │
 │ ─────────────────────────────>│ ────────────────────────> │

你是一位 IoT OTA 更新专家。为以下设备群设计 OTA 更新系统：

## 设备信息
- MCU：[型号]
- Flash 大小：[数值] MB
- 当前分区方案：[描述]
- 网络连接：[Wi-Fi/蜂窝/LoRaWAN]
- 设备数量：[数量]

## OTA 需求
1. 更新方式：[全量/差分/混合]
2. 更新触发：[设备轮询/服务器推送/手动]
3. 回滚策略：[自动回滚条件]
4. 灰度发布：[是否需要分批更新]
5. 断点续传：[是否需要]
6. 安全要求：[签名验证/加密传输/安全启动]

## 请设计
1. Flash 分区布局
2. OTA 更新流程（含回滚）
3. 固件签名和验证方案
4. 服务端架构（固件存储、版本管理、分发）
5. 灰度发布策略（百分比/设备组/地理区域）
6. 监控和告警（更新成功率、回滚率）
7. 差分更新方案（如适用）

你是一位 ESP-IDF OTA 专家。为 ESP32 实现安全 OTA 更新：

## 硬件
- 芯片：[ESP32 型号]
- Flash：[大小] MB
- 分区表：使用 OTA 分区方案

## 功能需求
1. HTTPS OTA：从服务器下载固件（TLS 验证）
2. 固件签名验证：使用 ECDSA/RSA 签名
3. 版本检查：只允许升级，不允许降级
4. 进度回调：上报下载和写入进度
5. 自动回滚：新固件启动后 [N] 秒内未确认则回滚
6. 断点续传：支持 HTTP Range 请求

## 安全要求
- 安全启动（Secure Boot v2）
- Flash 加密
- 固件签名密钥管理

## 代码规范
- 使用 esp_https_ota 组件
- 错误处理使用 esp_err_t
- OTA 过程中禁止其他 Flash 写入操作
- 更新状态通过 MQTT 上报

/* ota_manager.c - ESP32 安全 OTA 更新 */
#include "esp_ota_ops.h"
#include "esp_https_ota.h"
#include "esp_log.h"
 
static const char *TAG = "ota";
 
// ✅ OTA 完成后确认新固件
esp_err_t ota_confirm_image(void)
{
    const esp_partition_t *running = esp_ota_get_running_partition();
    esp_ota_img_states_t ota_state;
    
    if (esp_ota_get_state_partition(running, &ota_state) == ESP_OK) {
        if (ota_state == ESP_OTA_IMG_PENDING_VERIFY) {
            // ✅ 自检通过后确认固件
            ESP_LOGI(TAG, "确认新固件有效");
            esp_ota_mark_app_valid_cancel_rollback();
        }
    }
    return ESP_OK;
}
 
// ✅ 执行 OTA 更新
esp_err_t ota_perform_update(const char *url)
{
    ESP_LOGI(TAG, "开始 OTA 更新: %s", url);
    
    esp_http_client_config_t http_config = {
        .url = url,
        .cert_pem = server_cert_pem,  // ⚠️ 审查点：确保证书正确
        .timeout_ms = 30000,
        .keep_alive_enable = true,
    };
    
    esp_https_ota_config_t ota_config = {
        .http_config = &http_config,
        .partial_http_download = true,  // ✅ 支持断点续传
        .max_http_request_size = 4096,
    };
    
    esp_https_ota_handle_t ota_handle = NULL;
    esp_err_t err = esp_https_ota_begin(&ota_config, &ota_handle);
    if (err != ESP_OK) {
        ESP_LOGE(TAG, "OTA 初始化失败: %s", esp_err_to_name(err));
        return err;
    }
    
    // ✅ 分块下载和写入
    while (1) {
        err = esp_https_ota_perform(ota_handle);
        if (err != ESP_ERR_HTTPS_OTA_IN_PROGRESS) break;
        
        // 上报进度
        int progress = esp_https_ota_get_image_len_read(ota_handle) 
                       * 100 
                       / esp_https_ota_get_image_size(ota_handle);
        ESP_LOGI(TAG, "OTA 进度: %d%%", progress);
    }
    
    if (err == ESP_OK) {
        err = esp_https_ota_finish(ota_handle);
        if (err == ESP_OK) {
            ESP_LOGI(TAG, "OTA 成功，准备重启");
            esp_restart();  // ⚠️ 审查点：确保重启前保存必要状态
        }
    }
    
    esp_https_ota_abort(ota_handle);
    ESP_LOGE(TAG, "OTA 失败: %s", esp_err_to_name(err));
    return err;
}

你是一位 STM32 Bootloader 专家。为 [STM32 型号] 设计 OTA Bootloader：

## Flash 布局
- 总 Flash：[大小]
- Bootloader 区域：[起始地址]-[结束地址]（[大小]）
- App A 区域：[起始地址]-[结束地址]（[大小]）
- App B 区域：[起始地址]-[结束地址]（[大小]）
- 配置区域：[起始地址]-[结束地址]（[大小]）

## Bootloader 功能
1. 上电后检查更新标志
2. 验证固件完整性（CRC32 + 签名）
3. 选择启动分区（A 或 B）
4. 跳转到应用程序
5. 回滚支持（启动失败计数器）

## 应用层 OTA 功能
1. 通过 [MQTT/HTTP/UART] 接收固件
2. 写入非活动分区
3. 设置更新标志
4. 触发重启

## 安全要求
- 固件签名验证（ECDSA P-256）
- 防降级保护（版本号单调递增）
- 写保护 Bootloader 区域（Option Bytes）

服务端：
1. 保存所有历史固件版本
2. 收到设备当前版本号
3. 生成差分包：diff(旧版本, 新版本) → patch 文件
4. 签名差分包
5. 下发差分包

设备端：
1. 下载差分包（通常只有全量的 5-15%）
2. 验证差分包签名
3. 在 RAM 或临时 Flash 区域应用 patch
4. 验证生成的完整固件（SHA-256）
5. 写入目标分区
6. 重启验证

⚠️ 注意：差分更新需要设备端有足够 RAM 或临时存储空间

你是一位 IoT 安全架构师。设计设备身份管理方案：

## 设备信息
- 设备类型：[列出]
- 预估总量：[数量]
- 生产方式：[自产/OEM/第三方]
- 安全芯片：[有/无，型号]

## 安全要求
- 认证方式：[证书/Token/混合]
- 证书管理：[自建 CA/AWS IoT CA/Let's Encrypt]
- 密钥存储：[Flash/NVS 加密/安全芯片]
- 证书轮换：[是否需要，周期]

## 请设计
1. 设备身份生命周期（制造→注册→运行→退役）
2. 证书/密钥的生成和分发流程
3. 设备首次注册（provisioning）流程
4. 证书轮换策略
5. 设备撤销和黑名单机制
6. 批量注册方案（工厂预配置）

┌──────────┐                    ┌──────────────┐
│  物理设备  │                    │  设备影子(云端) │
│          │                    │              │
│ 当前状态: │  ──── 上报 ────>   │ reported: {  │
│ temp=25  │                    │   temp: 25   │
│ led=on   │                    │   led: "on"  │
│          │                    │ }            │
│          │  <── 下发期望 ───   │ desired: {   │
│          │                    │   led: "off" │
│          │                    │ }            │
│          │                    │              │
│ [执行命令]│                    │ delta: {     │
│ led=off  │  ──── 确认 ────>   │   led: "off" │
│          │                    │ }            │
└──────────┘                    └──────────────┘

设备离线时：
- 应用修改 desired 状态
- 设备上线后收到 delta（差异）
- 设备执行变更并上报 reported

你是一位 IoT 设备影子专家。为 [设备类型] 设计设备影子模型：

## 设备能力
- 传感器：[列出传感器和数据类型]
- 执行器：[列出可控制的执行器]
- 配置参数：[列出可远程配置的参数]
- 固件版本：[版本格式]

## 请设计
1. 设备影子 JSON 结构（reported / desired / metadata）
2. 状态上报策略（周期性 / 变更触发 / 混合）
3. 命令下发和确认机制
4. 离线场景处理
5. 影子版本冲突解决策略

## 平台
- [AWS IoT / Azure IoT / 自建]

{
  "state": {
    "reported": {
      "temperature": 25.3,
      "humidity": 62,
      "mode": "auto",
      "target_temp": 24,
      "fan_speed": "medium",
      "firmware": "2.1.0",
      "uptime": 86400,
      "rssi": -45,
      "last_error": null
    },
    "desired": {
      "target_temp": 22,
      "mode": "cool",
      "fan_speed": "high",
      "ota_url": null
    },
    "delta": {
      "target_temp": 22,
      "mode": "cool",
      "fan_speed": "high"
    }
  },
  "metadata": {
    "reported": {
      "temperature": { "timestamp": 1719849600 },
      "firmware": { "timestamp": 1719763200 }
    },
    "desired": {
      "target_temp": { "timestamp": 1719850000 }
    }
  },
  "version": 42,
  "timestamp": 1719850100
}

你是一位 IoT 设备群管理专家。设计大规模设备管理方案：

## 设备群信息
- 设备总数：[数量]
- 设备类型数：[数量]
- 地理分布：[区域列表]
- 网络条件：[稳定/不稳定/混合]

## 管理需求
1. 设备分组：按 [类型/区域/客户/固件版本] 分组
2. 批量配置：远程修改设备参数
3. 固件分发：灰度发布、分批更新
4. 监控告警：设备在线率、异常检测
5. 远程诊断：日志收集、远程调试

## 请设计
1. 设备分组和标签体系
2. 配置管理工作流（创建→审批→下发→确认）
3. 固件灰度发布策略
   - 金丝雀发布（1%→10%→50%→100%）
   - 回滚触发条件
   - 发布窗口（避开业务高峰）
4. 设备健康监控指标
5. 异常设备自动隔离策略

你是一位 IoT 数据分析专家。设计设备异常检测系统：

## 数据源
- 设备数量：[数量]
- 数据类型：[列出遥测数据字段]
- 数据频率：[频率]
- 历史数据量：[时间范围]

## 检测需求
1. 实时异常检测：[列出需要实时检测的异常]
2. 趋势异常检测：[列出需要趋势分析的指标]
3. 群体异常检测：[列出需要跨设备对比的指标]

## 技术约束
- 检测延迟：< [时间]
- 误报率：< [百分比]
- 计算资源：[边缘/云端/混合]

## 请设计
1. 异常检测算法选择（统计方法/ML 模型/规则引擎）
2. 数据预处理流水线
3. 告警分级和通知策略
4. 误报抑制机制
5. 异常根因分析辅助

设备证书生命周期：

制造阶段                运行阶段                退役阶段
┌──────────┐          ┌──────────┐          ┌──────────┐
│ 生成密钥对 │          │ 证书轮换  │          │ 证书吊销  │
│ 签发证书   │ ──────> │ 定期更新  │ ──────> │ 设备退役  │
│ 烧录到设备 │          │ CRL/OCSP │          │ 加入黑名单│
└──────────┘          └──────────┘          └──────────┘
     │                      │                      │
     ▼                      ▼                      ▼
 工厂 PKI              云端 CA 服务           设备管理平台
 离线签发              在线轮换               批量吊销

你是一位 IoT 安全专家。设计设备证书管理（PKI）方案：

## 设备规模
- 设备总数：[数量]
- 年新增设备：[数量]
- 设备生命周期：[年]

## 安全要求
- 证书类型：[自签名 CA / 公共 CA / 云平台 CA]
- 密钥算法：[RSA 2048 / ECC P-256 / Ed25519]
- 证书有效期：[年]
- 密钥存储：[Flash / 安全芯片 / TPM]

## 请设计
1. CA 层次结构（根 CA → 中间 CA → 设备证书）
2. 证书签发流程（工厂预配置 / 首次启动注册）
3. 证书轮换策略和自动化
4. 证书吊销机制（CRL / OCSP）
5. 密钥泄露应急响应流程
6. 与 [AWS IoT / Azure IoT] 的集成方案

你是一位嵌入式安全专家。为 [平台] 配置安全启动：

## 平台
- MCU：[型号]
- Bootloader：[内置/MCUboot/自定义]
- Flash 加密：[是否需要]

## 安全需求
1. 固件签名验证（启动时验证）
2. 防降级保护
3. Flash 加密（防止固件提取）
4. 调试接口锁定（JTAG/SWD 禁用）
5. 安全 OTA（签名验证 + 加密传输）

## 请提供
1. 安全启动配置步骤
2. 密钥生成和管理流程
3. 签名工具链配置
4. 生产线烧录流程（含密钥注入）
5. ⚠️ 不可逆操作警告清单（eFuse 烧录等）

你是一位 IoT 系统架构师。为 500 亩果园智能灌溉系统设计架构：

设备：200 个土壤传感器（ESP32-C3，LoRa，太阳能），
20 个电磁阀控制器（ESP32，LoRa），5 个气象站，
3 个 Raspberry Pi 5 边缘网关（4G 上行）。

需求：
1. 传感器每 15 分钟上报数据
2. 灌溉决策在边缘网关本地执行（低延迟）
3. 云端提供历史分析和 AI 灌溉建议
4. 支持离线运行（4G 断网时边缘自主决策）
5. OTA 更新所有设备
6. 成本敏感（创业公司预算有限）

请设计完整的三层架构。

┌─────────────────────────────────────────────────────┐
│                    ☁️ 云层                            │
│  ┌─────────────┐  ┌──────────┐  ┌──────────────┐   │
│  │ EMQX Cloud  │  │ InfluxDB │  │ AI 灌溉模型   │   │
│  │ MQTT Broker │  │ 时序存储  │  │ 历史分析      │   │
│  │ (Serverless)│  │ (Cloud)  │  │ 天气预测集成   │   │
│  └──────┬──────┘  └────┬─────┘  └──────┬───────┘   │
│         │              │               │            │
│  ┌──────┴──────────────┴───────────────┴───────┐   │
│  │           Web 仪表板 + 手机 App              │   │
│  │  实时监控 / 历史图表 / 灌溉计划 / 告警       │   │
│  └─────────────────────────────────────────────┘   │
├─────────────────────────────────────────────────────┤
│                  🔲 边缘层（×3 网关）                 │
│  ┌─────────────────────────────────────────────┐   │
│  │  Raspberry Pi 5 + LoRa 集中器                │   │
│  │  ├── Mosquitto（本地 MQTT Broker）            │   │
│  │  ├── 灌溉决策引擎（规则 + 简单 ML）           │   │
│  │  ├── 数据聚合和压缩                           │   │
│  │  ├── 离线缓存（SQLite）                       │   │
│  │  ├── LoRaWAN Network Server（ChirpStack）     │   │
│  │  └── 4G 上行（MQTT Bridge → EMQX Cloud）     │   │
│  └─────────────────────────────────────────────┘   │
├─────────────────────────────────────────────────────┤
│                  📱 设备层                            │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐         │
│  │ 土壤传感器 │  │ 电磁阀    │  │ 气象站    │         │
│  │ ESP32-C3 │  │ ESP32    │  │ ESP32    │         │
│  │ LoRa     │  │ LoRa     │  │ LoRa     │         │
│  │ 太阳能    │  │ 市电      │  │ 太阳能    │         │
│  │ 15min/次  │  │ 命令驱动  │  │ 5min/次   │         │
│  └──────────┘  └──────────┘  └──────────┘         │
└─────────────────────────────────────────────────────┘

# 智能农业 MQTT 主题设计

## 遥测数据（设备→网关→云）
farm/{farm-id}/zone/{zone-id}/sensor/{sensor-id}/telemetry
farm/{farm-id}/zone/{zone-id}/weather/{station-id}/telemetry
farm/{farm-id}/zone/{zone-id}/valve/{valve-id}/status

## 控制命令（云/网关→设备）
farm/{farm-id}/zone/{zone-id}/valve/{valve-id}/command

## 灌溉计划（云→网关）
farm/{farm-id}/zone/{zone-id}/irrigation/schedule

## 边缘网关状态
farm/{farm-id}/gateway/{gw-id}/status
farm/{farm-id}/gateway/{gw-id}/metrics

## OTA
ota/farm/{farm-id}/{device-type}/{device-id}/command
ota/farm/{farm-id}/{device-type}/{device-id}/status

# irrigation_engine.py - 边缘灌溉决策引擎（运行在 Pi 网关上）
import json
from datetime import datetime
 
class IrrigationEngine:
    """基于规则的灌溉决策引擎（边缘运行）"""
    
    def __init__(self, config):
        self.config = config
        self.soil_data = {}  # sensor_id -> latest reading
        self.weather_data = {}
    
    def update_soil(self, sensor_id, data):
        """更新土壤传感器数据"""
        self.soil_data[sensor_id] = {
            **data,
            "timestamp": datetime.now()
        }
    
    def update_weather(self, station_id, data):
        """更新气象站数据"""
        self.weather_data[station_id] = {
            **data,
            "timestamp": datetime.now()
        }
    
    def evaluate_zone(self, zone_id):
        """评估某区域是否需要灌溉"""
        zone_sensors = [
            s for sid, s in self.soil_data.items()
            if sid.startswith(f"zone-{zone_id}")
        ]
        
        if not zone_sensors:
            return {"action": "skip", "reason": "无传感器数据"}
        
        # 计算区域平均湿度
        avg_moisture = sum(
            s["moisture"] for s in zone_sensors
        ) / len(zone_sensors)
        
        # 检查天气预报（如果有降雨预报则跳过）
        weather = self.weather_data.get(f"zone-{zone_id}")
        if weather and weather.get("rain_forecast_mm", 0) > 5:
            return {
                "action": "skip",
                "reason": f"预报降雨 {weather['rain_forecast_mm']}mm"
            }
        
        # 灌溉决策
        threshold = self.config.get("moisture_threshold", 30)
        if avg_moisture < threshold:
            duration = self._calculate_duration(
                avg_moisture, threshold
            )
            return {
                "action": "irrigate",
                "duration_minutes": duration,
                "avg_moisture": avg_moisture,
                "threshold": threshold
            }
        
        return {
            "action": "skip",
            "reason": f"湿度 {avg_moisture:.1f}% >= 阈值 {threshold}%"
        }
    
    def _calculate_duration(self, current, target):
        """根据湿度差计算灌溉时长"""
        deficit = target - current
        # 简单线性模型：每 1% 湿度差 = 2 分钟灌溉
        return min(int(deficit * 2), 60)  # 最长 60 分钟

┌─────────────────────────────────────────────────────┐
│                    ☁️ 云层                            │
│  ┌──────────┐  ┌──────────┐  ┌──────────────────┐  │
│  │ HiveMQ   │  │TimescaleDB│  │ 预测性维护平台    │  │
│  │ Cloud    │  │ 历史数据  │  │ 趋势分析         │  │
│  │ MQTT 5.0 │  │ 长期存储  │  │ 维护计划优化     │  │
│  └──────────┘  └──────────┘  │ 备件库存预测     │  │
│                              └──────────────────┘  │
├─────────────────────────────────────────────────────┤
│              🔲 边缘层（每 10 台机床 1 个节点）        │
│  ┌─────────────────────────────────────────────┐   │
│  │  NVIDIA Jetson Orin Nano                     │   │
│  │  ├── 振动分析 AI（ONNX Runtime）              │   │
│  │  │   ├── 频谱分析（FFT）                      │   │
│  │  │   ├── 轴承故障检测                         │   │
│  │  │   └── 异常评分（0-100）                    │   │
│  │  ├── 本地 MQTT Broker（NanoMQ）               │   │
│  │  ├── 数据降采样（4kHz → 特征值）              │   │
│  │  ├── 告警引擎（实时告警 < 100ms）             │   │
│  │  └── 边缘数据库（InfluxDB Edge）              │   │
│  └─────────────────────────────────────────────┘   │
├─────────────────────────────────────────────────────┤
│                  📱 设备层（×50 机床）                │
│  ┌──────────────────────────────────────────┐      │
│  │  数据采集单元（STM32H7 + 以太网）          │      │
│  │  ├── 3 轴加速度计（ADXL355，4kHz）        │      │
│  │  ├── 温度传感器（PT100，1Hz）             │      │
│  │  ├── 电流传感器（霍尔，1kHz）             │      │
│  │  ├── MQTT 客户端（QoS 1）                 │      │
│  │  └── 本地缓存（断网时缓存 1 小时数据）     │      │
│  └──────────────────────────────────────────┘      │
└─────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────┐
│              智能家居网关架构                  │
├─────────────────────────────────────────────┤
│  ESP32-S3（主控 + Wi-Fi）                    │
│  ├── Matter Controller                       │
│  ├── 本地自动化引擎                           │
│  ├── mDNS 服务发现                           │
│  ├── Wi-Fi 设备通信                          │
│  └── 云端连接（MQTT → HomeKit/Google/Alexa） │
├─────────────────────────────────────────────┤
│  ESP32-H2（Thread Border Router）            │
│  ├── Thread 网络管理                         │
│  ├── 802.15.4 ↔ Wi-Fi/以太网 桥接           │
│  └── Thread 设备 commissioning               │
├─────────────────────────────────────────────┤
│  Thread 设备网络                              │
│  ├── 灯泡（Thread + Matter）                 │
│  ├── 门锁（Thread + Matter）                 │
│  ├── 温控器（Thread + Matter）               │
│  └── 传感器（Thread + Matter）               │
└─────────────────────────────────────────────┘