---

layout: default title: 边缘计算基础功能 description: EdgeX 边缘计算基础功能 —

边缘计算插件方案设计文档（基础功能）

第一阶段：基础框架设计（数据流闭环 + 规则执行骨架）

一、阶段目标

第一阶段的核心目标是构建一个可稳定运行、结构清晰、易扩展的边缘计算基础框架，实现以下能力：

1. 建立标准化的数据流通道（采集 → 处理 → 输出）
2. 实现基础规则执行引擎（事件驱动）
3. 支持多规则并行处理同一数据源（非共享源模式）
4. 打通南向采集与北向输出的标准接口
5. 形成完整的运行闭环和可观测能力

该阶段不追求高复杂度计算或极致性能优化，而是为后续共享源、窗口计算、高级分析能力奠定稳定、清晰、可维护的架构基础。

---

二、总体架构设计

第一阶段采用事件驱动型数据流处理模型，整体架构分为五个核心层次：

1. 数据输入层（Input Layer）
2. 数据调度层（Dispatch Layer）
3. 规则执行层（Rule Execution Layer）
4. 结果处理层（Result Handling Layer）
5. 运维监控层（Observability Layer）

逻辑链路如下：

南向采集模块 → 数据输入适配器 → 规则调度引擎 → 规则执行单元 → 结果处理器 → 北向输出模块 / 本地动作模块

该结构确保系统满足：

• 高内聚、低耦合
• 规则模块可插拔
• 数据通道可扩展
• 输出方式可配置

---

三、核心功能模块设计

3.1 数据输入层（Input Layer）

职责定位：

• 接收来自南向采集系统的实时数据流；
• 将原始数据转换为统一标准的数据结构；
• 负责数据的初步校验与基础清洗。

功能要求：

1. 支持多协议采集适配（Modbus、BACnet、OPC UA、MQTT 等）

2. 统一数据格式抽象，包含：

   • 数据源标识（SourceID）
   • 指标名称（Metric）
   • 数据值（Value）
   • 时间戳（Timestamp）
   • 质量标识（Quality，可选）

3. 支持数据合法性校验：

   • 时间戳合理性检查
   • 数据类型校验
   • 质量标志过滤（如通信异常、校验失败）

设计约束：

• 输入层不承担任何业务计算逻辑；
• 不应缓存长期数据；
• 必须保证输入数据结构的一致性。

---

3.2 数据调度层（Dispatch Layer）

职责定位：

• 接收标准化数据；
• 根据规则订阅关系，将数据分发给对应规则；
• 管理规则注册、卸载、启停状态。

功能要求：

1. 规则注册与注销机制
2. 支持规则启用/禁用（不删除规则配置）
3. 支持运行时规则热更新（不中断系统运行）
4. 支持规则执行顺序控制（基础优先级）

调度模型：

• 每条输入数据事件会被广播给所有启用规则；
• 每个规则独立处理数据，不相互依赖、不共享状态（第一阶段不引入共享源）。

设计原则：

• 调度层不关心规则内部逻辑；
• 调度层不关心输出目标；
• 调度层只负责“谁该处理这条数据”。

---

3.3 规则执行层（Rule Execution Layer）

职责定位：

• 承载具体业务计算逻辑；
• 以事件触发方式响应数据输入；
• 输出规则匹配结果或计算结果。

规则类型（第一阶段支持）：

1. 条件判断规则

   • 阈值告警：>、<、≥、≤
   • 状态切换：如 OFF → ON、0 → 1
   • 变化幅度判断：Δ值超限

2. 简单计算规则

   • 数值变换（线性缩放、单位换算）
   • 数据映射（枚举值转换）
   • 固定公式计算

3. 状态判断规则

   • 状态保持时间判断（持续超限 N 秒）
   • 去抖处理（抑制短时波动）

规则生命周期：

• 创建 → 校验 → 启用 → 执行 → 停用 → 删除

规则执行约束：

• 单次执行时间必须可控（建议 < 10ms）
• 不允许阻塞主数据通道
• 不允许直接操作外部系统（必须通过结果处理层）

---

3.4 结果处理层（Result Handling Layer）

职责定位：

• 接收规则输出结果；
• 根据规则配置执行对应动作；
• 解耦规则逻辑与外部系统调用。

支持的输出动作类型：

1. 北向上报

   • MQTT 发布
   • HTTP 推送
   • WebSocket 推送

2. 本地动作

   • 本地日志记录
   • 本地数据库存储
   • 文件缓存（支持断网续传）

3. 控制指令

   • 下发控制命令到设备（如 Modbus 写、BACnet 控制）
   • 联动其他子系统（如空调、照明、门禁）

4. 告警通知

   • UI 界面提示
   • 短信 / 邮件 / 企业微信 / 钉钉

设计原则：

• 输出动作必须配置化，不硬编码；
• 同一规则可绑定多个输出动作；
• 输出失败必须支持重试机制或失败记录。

---

3.5 运维与监控层（Observability Layer）

职责定位：

• 提供系统运行可视化能力；
• 支持调试、诊断、审计与性能分析。

基础监控指标：

• 输入数据吞吐量
• 规则执行次数
• 规则执行耗时分布
• 告警触发频率
• 输出成功率 / 失败率

基础运维功能：

• 规则运行状态监控
• 规则最近一次触发时间
• 规则最近一次失败原因
• 系统健康状态展示

---

四、配置模型设计（第一阶段）

4.1 数据源配置模型

• 数据源ID
• 数据源类型（南向采集 / 北向订阅）
• 协议类型
• 连接参数
• 数据点映射关系
• 采集频率
• 数据质量策略

4.2 规则配置模型

• 规则ID
• 规则名称
• 规则类型（阈值/计算/状态）
• 绑定数据源
• 计算表达式或条件表达式
• 触发条件
• 输出动作列表
• 启用状态
• 优先级

4.3 输出动作配置模型

• 动作类型（上报/告警/控制/存储）
• 目标地址或通道
• 数据格式
• 重试策略
• 失败处理策略

---

五、第一阶段交付成果标准

系统需达到以下状态才可视为阶段完成：

1. 能稳定接入南向采集数据
2. 能成功配置并执行至少三类规则
3. 能输出结果到至少两种不同通道
4. 支持规则热启停与动态更新
5. 具备基本运行监控与日志能力

---

---

第二阶段：时间窗口与状态管理设计（流处理能力增强）

一、阶段目标

第二阶段在第一阶段基础上，引入时间维度、状态缓存与统计计算能力，实现以下能力：

1. 支持基于时间窗口的统计计算（平均值、最大值、最小值、变化率等）
2. 支持规则级状态管理与历史上下文存储
3. 支持复杂条件组合（时间 + 值 + 状态）
4. 提升边缘计算的业务表达能力，满足实际工业场景需求
5. 为第三阶段共享源机制与并发优化提供基础设施

---

二、总体能力扩展结构

第二阶段引入两个核心增强模块：

1. 窗口管理子系统（Window Management Subsystem）
2. 规则状态管理子系统（Rule State Management Subsystem）

逻辑结构如下：

数据输入 → 数据调度 → 窗口缓存 → 状态更新 → 规则计算 → 结果输出

窗口与状态将成为规则执行的一等公民，不再是规则内部临时变量，而是系统级可管理对象。

---

三、窗口管理子系统设计

3.1 窗口类型支持

系统需支持以下标准窗口模型：

1. 滑动窗口（Sliding Window）

   • 固定大小窗口，随时间滚动更新
   • 适用于平均值、平滑滤波、短期趋势分析

2. 跳跃窗口（Tumbling Window）

   • 固定时间段内聚合计算
   • 适用于定时报表、批量统计

3. 会话窗口（Session Window，第二阶段可选支持）

   • 根据事件间隔动态分组
   • 适用于行为模式分析

第二阶段至少必须支持：滑动窗口 + 跳跃窗口。

---

3.2 窗口参数模型

每个窗口实例必须具备以下参数：

• 窗口ID
• 窗口类型
• 绑定规则ID
• 绑定数据源ID
• 窗口大小（条数或时间长度）
• 滑动步长（如适用）
• 缓存策略（环形缓冲、链表等）
• 数据过期策略
• 内存上限

---

3.3 窗口生命周期管理

窗口对象的生命周期由规则生命周期驱动：

1. 规则创建 → 窗口实例创建
2. 规则启用 → 窗口开始接收数据
3. 规则停用 → 窗口暂停接收数据
4. 规则删除 → 窗口实例释放资源

系统必须支持：

• 窗口动态创建与销毁；
• 窗口配置变更时平滑过渡；
• 防止窗口内存泄露。

---

3.4 窗口数据一致性与完整性

系统需保证：

1. 窗口数据顺序一致性（按时间戳排序）
2. 窗口数据完整性（不遗漏、不重复）
3. 窗口计算确定性（相同输入必然得到相同输出）

在数据乱序、延迟、抖动场景下，应提供以下机制：

• 时间戳校正策略
• 最大延迟容忍窗口
• 迟到数据处理策略（丢弃 / 补算 / 标记）

---

四、规则状态管理子系统设计

4.1 规则状态模型

每条规则必须具备独立、持久的运行状态对象，包括但不限于：

• 最近一次触发时间
• 最近一次触发值
• 当前状态值（如 NORMAL / ALARM / RECOVER）
• 持续时间计数器
• 触发次数统计
• 最近一次错误信息

这些状态必须在规则执行过程中持续更新，并可被外部监控系统读取。

---

4.2 状态持久化策略

系统应支持多级状态存储：

1. 内存态（实时运行态）
2. 本地持久态（文件 / 嵌入式数据库）
3. 可选远程态（云端同步，后续阶段扩展）

在系统重启、崩溃恢复后，应尽可能恢复规则的运行上下文，避免丢失关键业务状态。

---

4.3 状态驱动规则逻辑

第二阶段规则逻辑必须支持基于历史状态进行判断，例如：

• 持续超限 N 秒后才触发告警
• 连续 K 次异常才触发告警
• 状态变化才触发动作（防止重复告警）
• 从异常恢复到正常才触发恢复事件

规则表达能力必须支持：

• 时间条件 + 值条件 + 状态条件 的组合判断
• 状态转移模型（有限状态机）

---

五、增强规则类型设计（第二阶段）

第二阶段在第一阶段基础上，新增以下规则类型：

1. 窗口统计规则

   • 滑动平均告警
   • 最大值 / 最小值告警
   • 波动率检测
   • 变化趋势判断

2. 持续状态规则

   • 持续超限 N 秒
   • 持续异常 K 次
   • 状态稳定性检测

3. 变化率规则

   • 突变检测（Δ值超过阈值）
   • 上升/下降速率检测

4. 组合规则

   • 多条件 AND / OR 组合
   • 跨时间段对比规则（如当前窗口 vs 前一窗口）

---

六、执行模型与性能设计

6.1 执行时序模型

数据处理顺序应为：

1. 数据进入系统
2. 写入对应窗口缓存
3. 更新规则状态
4. 执行规则逻辑判断
5. 生成规则结果
6. 触发输出动作

该顺序必须保证：

• 状态更新在规则判断之前完成；
• 输出动作仅在规则匹配成功后执行；
• 状态与窗口数据对规则判断是可见且一致的。

---

6.2 性能与资源约束

第二阶段引入窗口与状态管理后，系统需满足：

• 单窗口最大缓存容量可配置；
• 系统内窗口总数可控；
• 状态存储与读取时间必须稳定（建议 < 5ms）；
• 单规则计算耗时不得超过预期阈值（如 20ms）；
• 窗口计算与规则执行不得阻塞主数据通道。

---

七、异常处理与健壮性设计（第二阶段）

系统需具备以下异常处理能力：

1. 窗口数据异常处理

   • 窗口溢出保护
   • 数据格式错误过滤
   • 时间戳异常修正或丢弃

2. 状态异常处理

   • 状态对象损坏恢复机制
   • 状态持久化失败重试
   • 状态与规则不一致修复机制

3. 规则执行异常处理

   • 单规则异常不得影响其他规则执行
   • 异常必须记录并可追溯
   • 支持规则自动降级或自动禁用策略（可配置）

---

八、配置模型扩展（第二阶段）

8.1 窗口配置模型扩展字段

• 窗口类型
• 窗口大小（条数 / 时间）
• 滑动步长
• 最大延迟容忍时间
• 数据过期策略
• 内存上限

8.2 状态管理配置字段

• 状态持久化开关
• 状态持久化周期
• 状态恢复策略
• 状态保留周期

8.3 规则表达式增强字段

• 时间条件表达式
• 状态条件表达式
• 多条件组合逻辑
• 状态转移定义

---

九、第二阶段交付成果标准

系统需达到以下标准：

1. 支持至少两种窗口模型（滑动 + 跳跃）
2. 支持窗口统计类规则稳定运行
3. 支持状态驱动规则（持续时间、连续次数）
4. 系统重启后可恢复规则状态
5. 窗口与状态资源使用可监控、可限制
6. 在高频数据流下，系统稳定运行无明显性能退化