layout: default title: 边缘计算基础功能 description: EdgeX 边缘计算基础功能 —
边缘计算插件方案设计文档（基础功能）
第一阶段：基础框架设计（数据流闭环 + 规则执行骨架）
一、阶段目标
第一阶段的核心目标是构建一个可稳定运行、结构清晰、易扩展的边缘计算基础框架，实现以下能力：
- 建立标准化的数据流通道（采集 → 处理 → 输出）
- 实现基础规则执行引擎（事件驱动）
- 支持多规则并行处理同一数据源（非共享源模式）
- 打通南向采集与北向输出的标准接口
- 形成完整的运行闭环和可观测能力
该阶段不追求高复杂度计算或极致性能优化，而是为后续共享源、窗口计算、高级分析能力奠定稳定、清晰、可维护的架构基础。
二、总体架构设计
第一阶段采用事件驱动型数据流处理模型，整体架构分为五个核心层次：
- 数据输入层（Input Layer）
- 数据调度层（Dispatch Layer）
- 规则执行层（Rule Execution Layer）
- 结果处理层（Result Handling Layer）
- 运维监控层（Observability Layer）
逻辑链路如下：
南向采集模块 → 数据输入适配器 → 规则调度引擎 → 规则执行单元 → 结果处理器 → 北向输出模块 / 本地动作模块
该结构确保系统满足：
- 高内聚、低耦合
- 规则模块可插拔
- 数据通道可扩展
- 输出方式可配置
三、核心功能模块设计
3.1 数据输入层（Input Layer）
职责定位：
- 接收来自南向采集系统的实时数据流；
- 将原始数据转换为统一标准的数据结构；
- 负责数据的初步校验与基础清洗。
功能要求：
- 支持多协议采集适配（Modbus、BACnet、OPC UA、MQTT 等）
-
统一数据格式抽象，包含：
- 数据源标识（SourceID）
- 指标名称（Metric）
- 数据值（Value）
- 时间戳（Timestamp）
- 质量标识（Quality，可选）
-
支持数据合法性校验：
- 时间戳合理性检查
- 数据类型校验
- 质量标志过滤（如通信异常、校验失败）
设计约束：
- 输入层不承担任何业务计算逻辑；
- 不应缓存长期数据；
- 必须保证输入数据结构的一致性。
3.2 数据调度层（Dispatch Layer）
职责定位：
- 接收标准化数据；
- 根据规则订阅关系，将数据分发给对应规则；
- 管理规则注册、卸载、启停状态。
功能要求：
- 规则注册与注销机制
- 支持规则启用/禁用（不删除规则配置）
- 支持运行时规则热更新（不中断系统运行）
- 支持规则执行顺序控制（基础优先级）
调度模型：
- 每条输入数据事件会被广播给所有启用规则；
- 每个规则独立处理数据，不相互依赖、不共享状态（第一阶段不引入共享源）。
设计原则：
- 调度层不关心规则内部逻辑；
- 调度层不关心输出目标；
- 调度层只负责“谁该处理这条数据”。
3.3 规则执行层（Rule Execution Layer）
职责定位：
- 承载具体业务计算逻辑；
- 以事件触发方式响应数据输入；
- 输出规则匹配结果或计算结果。
规则类型（第一阶段支持）：
-
条件判断规则
- 阈值告警：>、<、≥、≤
- 状态切换：如 OFF → ON、0 → 1
- 变化幅度判断：Δ值超限
-
简单计算规则
- 数值变换（线性缩放、单位换算）
- 数据映射（枚举值转换）
- 固定公式计算
-
状态判断规则
- 状态保持时间判断（持续超限 N 秒）
- 去抖处理（抑制短时波动）
规则生命周期：
- 创建 → 校验 → 启用 → 执行 → 停用 → 删除
规则执行约束：
- 单次执行时间必须可控（建议 < 10ms）
- 不允许阻塞主数据通道
- 不允许直接操作外部系统（必须通过结果处理层）
3.4 结果处理层（Result Handling Layer）
职责定位：
- 接收规则输出结果；
- 根据规则配置执行对应动作；
- 解耦规则逻辑与外部系统调用。
支持的输出动作类型：
-
北向上报
- MQTT 发布
- HTTP 推送
- WebSocket 推送
-
本地动作
- 本地日志记录
- 本地数据库存储
- 文件缓存（支持断网续传）
-
控制指令
- 下发控制命令到设备（如 Modbus 写、BACnet 控制）
- 联动其他子系统（如空调、照明、门禁）
-
告警通知
- UI 界面提示
- 短信 / 邮件 / 企业微信 / 钉钉
设计原则：
- 输出动作必须配置化，不硬编码；
- 同一规则可绑定多个输出动作；
- 输出失败必须支持重试机制或失败记录。
3.5 运维与监控层（Observability Layer）
职责定位：
- 提供系统运行可视化能力；
- 支持调试、诊断、审计与性能分析。
基础监控指标：
- 输入数据吞吐量
- 规则执行次数
- 规则执行耗时分布
- 告警触发频率
- 输出成功率 / 失败率
基础运维功能：
- 规则运行状态监控
- 规则最近一次触发时间
- 规则最近一次失败原因
- 系统健康状态展示
四、配置模型设计（第一阶段）
4.1 数据源配置模型
- 数据源ID
- 数据源类型（南向采集 / 北向订阅）
- 协议类型
- 连接参数
- 数据点映射关系
- 采集频率
- 数据质量策略
4.2 规则配置模型
- 规则ID
- 规则名称
- 规则类型（阈值/计算/状态）
- 绑定数据源
- 计算表达式或条件表达式
- 触发条件
- 输出动作列表
- 启用状态
- 优先级
4.3 输出动作配置模型
- 动作类型（上报/告警/控制/存储）
- 目标地址或通道
- 数据格式
- 重试策略
- 失败处理策略
五、第一阶段交付成果标准
系统需达到以下状态才可视为阶段完成：
- 能稳定接入南向采集数据
- 能成功配置并执行至少三类规则
- 能输出结果到至少两种不同通道
- 支持规则热启停与动态更新
- 具备基本运行监控与日志能力
第二阶段：时间窗口与状态管理设计（流处理能力增强）
一、阶段目标
第二阶段在第一阶段基础上，引入时间维度、状态缓存与统计计算能力，实现以下能力：
- 支持基于时间窗口的统计计算（平均值、最大值、最小值、变化率等）
- 支持规则级状态管理与历史上下文存储
- 支持复杂条件组合（时间 + 值 + 状态）
- 提升边缘计算的业务表达能力，满足实际工业场景需求
- 为第三阶段共享源机制与并发优化提供基础设施
二、总体能力扩展结构
第二阶段引入两个核心增强模块：
- 窗口管理子系统（Window Management Subsystem）
- 规则状态管理子系统（Rule State Management Subsystem）
逻辑结构如下：
数据输入 → 数据调度 → 窗口缓存 → 状态更新 → 规则计算 → 结果输出
窗口与状态将成为规则执行的一等公民，不再是规则内部临时变量，而是系统级可管理对象。
三、窗口管理子系统设计
3.1 窗口类型支持
系统需支持以下标准窗口模型：
-
滑动窗口（Sliding Window）
- 固定大小窗口，随时间滚动更新
- 适用于平均值、平滑滤波、短期趋势分析
-
跳跃窗口（Tumbling Window）
- 固定时间段内聚合计算
- 适用于定时报表、批量统计
-
会话窗口（Session Window，第二阶段可选支持）
- 根据事件间隔动态分组
- 适用于行为模式分析
第二阶段至少必须支持：滑动窗口 + 跳跃窗口。
3.2 窗口参数模型
每个窗口实例必须具备以下参数：
- 窗口ID
- 窗口类型
- 绑定规则ID
- 绑定数据源ID
- 窗口大小（条数或时间长度）
- 滑动步长（如适用）
- 缓存策略（环形缓冲、链表等）
- 数据过期策略
- 内存上限
3.3 窗口生命周期管理
窗口对象的生命周期由规则生命周期驱动：
- 规则创建 → 窗口实例创建
- 规则启用 → 窗口开始接收数据
- 规则停用 → 窗口暂停接收数据
- 规则删除 → 窗口实例释放资源
系统必须支持：
- 窗口动态创建与销毁；
- 窗口配置变更时平滑过渡；
- 防止窗口内存泄露。
3.4 窗口数据一致性与完整性
系统需保证：
- 窗口数据顺序一致性（按时间戳排序）
- 窗口数据完整性（不遗漏、不重复）
- 窗口计算确定性（相同输入必然得到相同输出）
在数据乱序、延迟、抖动场景下，应提供以下机制：
- 时间戳校正策略
- 最大延迟容忍窗口
- 迟到数据处理策略（丢弃 / 补算 / 标记）
四、规则状态管理子系统设计
4.1 规则状态模型
每条规则必须具备独立、持久的运行状态对象，包括但不限于：
- 最近一次触发时间
- 最近一次触发值
- 当前状态值（如 NORMAL / ALARM / RECOVER）
- 持续时间计数器
- 触发次数统计
- 最近一次错误信息
这些状态必须在规则执行过程中持续更新，并可被外部监控系统读取。
4.2 状态持久化策略
系统应支持多级状态存储：
- 内存态（实时运行态）
- 本地持久态（文件 / 嵌入式数据库）
- 可选远程态（云端同步，后续阶段扩展）
在系统重启、崩溃恢复后，应尽可能恢复规则的运行上下文，避免丢失关键业务状态。
4.3 状态驱动规则逻辑
第二阶段规则逻辑必须支持基于历史状态进行判断，例如：
- 持续超限 N 秒后才触发告警
- 连续 K 次异常才触发告警
- 状态变化才触发动作（防止重复告警）
- 从异常恢复到正常才触发恢复事件
规则表达能力必须支持：
- 时间条件 + 值条件 + 状态条件 的组合判断
- 状态转移模型（有限状态机）
五、增强规则类型设计（第二阶段）
第二阶段在第一阶段基础上，新增以下规则类型：
-
窗口统计规则
- 滑动平均告警
- 最大值 / 最小值告警
- 波动率检测
- 变化趋势判断
-
持续状态规则
- 持续超限 N 秒
- 持续异常 K 次
- 状态稳定性检测
-
变化率规则
- 突变检测（Δ值超过阈值）
- 上升/下降速率检测
-
组合规则
- 多条件 AND / OR 组合
- 跨时间段对比规则（如当前窗口 vs 前一窗口）
六、执行模型与性能设计
6.1 执行时序模型
数据处理顺序应为：
- 数据进入系统
- 写入对应窗口缓存
- 更新规则状态
- 执行规则逻辑判断
- 生成规则结果
- 触发输出动作
该顺序必须保证：
- 状态更新在规则判断之前完成；
- 输出动作仅在规则匹配成功后执行；
- 状态与窗口数据对规则判断是可见且一致的。
6.2 性能与资源约束
第二阶段引入窗口与状态管理后，系统需满足：
- 单窗口最大缓存容量可配置；
- 系统内窗口总数可控；
- 状态存储与读取时间必须稳定（建议 < 5ms）；
- 单规则计算耗时不得超过预期阈值（如 20ms）；
- 窗口计算与规则执行不得阻塞主数据通道。
七、异常处理与健壮性设计（第二阶段）
系统需具备以下异常处理能力：
-
窗口数据异常处理
- 窗口溢出保护
- 数据格式错误过滤
- 时间戳异常修正或丢弃
-
状态异常处理
- 状态对象损坏恢复机制
- 状态持久化失败重试
- 状态与规则不一致修复机制
-
规则执行异常处理
- 单规则异常不得影响其他规则执行
- 异常必须记录并可追溯
- 支持规则自动降级或自动禁用策略（可配置）
八、配置模型扩展（第二阶段）
8.1 窗口配置模型扩展字段
- 窗口类型
- 窗口大小（条数 / 时间）
- 滑动步长
- 最大延迟容忍时间
- 数据过期策略
- 内存上限
8.2 状态管理配置字段
- 状态持久化开关
- 状态持久化周期
- 状态恢复策略
- 状态保留周期
8.3 规则表达式增强字段
- 时间条件表达式
- 状态条件表达式
- 多条件组合逻辑
- 状态转移定义
九、第二阶段交付成果标准
系统需达到以下标准：
- 支持至少两种窗口模型（滑动 + 跳跃）
- 支持窗口统计类规则稳定运行
- 支持状态驱动规则（持续时间、连续次数）
- 系统重启后可恢复规则状态
- 窗口与状态资源使用可监控、可限制
- 在高频数据流下，系统稳定运行无明显性能退化