曲线分析系统技术领域知识
本文只补充技术实现视角，不重复业务定义。重点说明曲线分析系统的架构位置、数据流转、边缘端计算、云端规则判定和结果回写机制。
与前两篇笔记的关系
- 前两篇笔记回答“系统要解决什么问题、业务对象是什么、结果如何分层”。
- 本笔记回答“这些能力在系统里如何实现、数据如何流转、计算在哪里发生、规则在哪里执行”。
- 三篇笔记的分工是互补的，不应重复定义同一套业务对象。
技术架构总览
曲线分析系统从运行位置上可以拆成两大部分：
- 边缘端：靠近设备和在线节点，负责曲线数据获取、曲线构造、预处理、模型推理和策略执行，最终产出可存储、可同步的策略运行结果。
- 云端：靠近配置中心、事件中心和数据中心，负责规则配置管理、规则作用域筛选、规则判定、事件生成和结果留痕。
这张图需要特别强调两条边界：
- 数据与计算位置：原始曲线数据在现场产生，曲线构造、对齐、模型推理和策略执行尽量在边缘端完成，减少云端实时计算压力。
- 判定位置：规则判定在云端执行。边缘端只把策略结果同步上来，云端根据设备、分类号、规则类型和规则表达式决定是否生成事件。
关键数据流转
曲线分析的数据流转可以理解为“现场形成曲线，边缘形成策略结果，云端形成规则结论和事件”。
| 现场设备 | 边缘端在线节点 | 云端配置中心 | 云端结果中心 | 云端规则判定 | 事件中心 |
|---|---|---|---|---|---|
| 设备待机 / 拧紧开始 | 1. 下发配置 模型、策略、采集项映射 |
||||
| 2. 产生过程数据 扭矩、角度、时间 |
→ 接收上报 | ||||
| 3. 边缘端计算 曲线构造、对齐、截取、特征计算、模型推理 |
← 使用配置 | ||||
| 4. 策略执行 生成实际运行的策略结果 |
→ 同步策略结果 | ||||
| 5. 提供规则配置 规则、scope、规则类型 |
6. 提供结果记录 策略结果、判定因子 |
7. 云端规则判定 作用域筛选、类型筛选、direct / combination |
|||
| 8. 写入规则结论 OK / NOK / 跳过 |
NOK → | 9. 生成事件 仅最终 NOK 进入事件中心 |
| 阶段 | 主要位置 | 输入 | 输出 | 说明 |
|---|---|---|---|---|
| 采集与上报 | 现场设备、在线节点 | 扭矩、角度、时间、设备、分类号 | 原始时序数据 | 数据首先在现场产生，不依赖云端实时查询。 |
| 曲线构造 | 边缘端 | 原始时序数据、采集项映射 | 可分析曲线 | 完成扭矩和角度序列的组合、截取和基础清洗。 |
| 预处理与模型计算 | 边缘端 | 可分析曲线、模型配置 | 特征值、模型分值、判定因子 | 包括特征计算、机器学习模型推理、神经网络模型推理。 |
| 策略执行 | 边缘端 | 判定因子、策略配置 | 单个策略运行结果 | 策略把模型能力转换为统一的通过、不通过或其他标准化结果。 |
| 结果同步 | 边缘端到云端 | 曲线摘要、策略结果、判定因子 | 云端结果记录 | 云端后续基于这些结果做规则判定和追溯。 |
| 规则判定 | 云端 | 策略结果、规则配置、scope | OK、NOK、跳过 | 规则只编排和判断策略结果，不重新执行模型推理。 |
| 事件生成 | 云端 | NOK 规则结论 | 事件记录 | 只有最终结果为 NOK 才生成事件。 |
关键技术决策
这些技术决策决定了系统在数据一致性、算力部署和标准曲线治理上的实现边界。
| 技术决策 | 决策内容 | 主要收益 | 约束与影响 |
|---|---|---|---|
| 节点计算采用内存计算 | 边缘端在一次计算链路中直接完成曲线构造、预处理、模型推理和策略执行，不额外落中间表。 | 避免中间表状态、重算数据和最终结果之间的一致性复杂度。 | 需要保证单次计算过程具备完整输入，失败后通过原始曲线和配置重新触发计算。 |
| 系统进行算力分级 | 基础版包含机器学习模型；算力版包含神经网络；高算力版包含智能体能力。 | 让功能能力与现场硬件、部署成本和客户场景匹配。 | 策略和模型配置需要标记所需算力等级，避免低算力节点执行超出能力范围的任务。 |
| 参考曲线采用复合标准 | 参考曲线 = 人工指定标准 + 模型训练标准 + 人工复核；一个分类号下保留一条参考曲线。 | 兼顾工艺经验、数据训练结果和人工确认，避免同一分类号存在多个互相冲突的标准。 | 参考曲线需要有版本、复核状态和生效状态，更新时应明确替换关系。 |
1. 节点计算采用内存计算
节点计算链路采用内存计算，不使用中间表承接曲线构造、特征计算、模型推理和策略执行之间的临时状态。
这个决策的核心原因是减少重新计算时的数据一致性复杂度。如果每个阶段都落中间表，系统需要额外处理“中间表是否过期、配置是否已变更、重算是否覆盖旧结果、部分阶段成功但最终阶段失败”等问题。采用内存计算后，一次策略执行可以被视为一个完整计算单元，最终只落策略结果、判定因子和必要的曲线摘要。
该决策并不表示系统不能重算，而是重算应基于原始曲线数据、当前生效配置和明确的任务触发重新完成整条计算链路，而不是依赖历史中间表继续向后计算。
2. 系统进行算力分级
系统能力按算力分级交付：
- 基础版：包含机器学习模型能力，适合常规特征、传统模型和轻量异常评分。
- 算力版：包含神经网络能力，适合更复杂的曲线模式识别、深度模型推理和模型平台接入。
- 高算力版：包含智能体能力，适合更复杂的自动分析、辅助解释、策略编排建议和跨数据源推理。
算力分级的价值，是让边缘端部署能力与现场硬件条件、客户预算和业务复杂度匹配。不是所有现场都需要神经网络或智能体能力，基础版可以覆盖大多数稳定工艺场景；当曲线形态复杂、异常类型难以显式建模时，再升级到更高算力版本。
因此，模型、策略和任务配置需要带有所需算力等级。调度执行前应先判断当前节点是否具备对应能力，避免把高算力任务下发到基础节点后再失败。
3. 参考曲线采用复合标准
参考曲线不是单纯由人工指定，也不是完全由模型训练自动生成，而是由三部分共同形成：
- 人工指定标准：来自工艺经验、现场专家判断或历史认可样本。
- 模型训练标准：来自样本集合训练后的标准曲线、阈值或分布特征。
- 人工复核：对模型训练结果进行确认、修正和生效控制。
一个分类号下只保留一条参考曲线，避免同一分类号存在多个相互竞争的标准。这样做可以让策略执行、规则判定和结果解释都基于同一条当前生效标准，减少“同一条曲线按不同参考标准得到不同结论”的歧义。
参考曲线更新时，应保留版本和复核记录。新参考曲线生效后替换旧参考曲线，旧版本用于追溯，不再参与新的策略计算。
边缘端计算链路
边缘端计算链路的目标，是把一次拧紧过程中的原始时序数据转成一组可同步的策略运行结果。
1. 曲线数据构造
曲线不是直接拿来就能算，通常要先做数据构造。
核心步骤是：
- 根据设备和分类号找到采集项映射。
- 找到采集项对应的在线节点。
- 从节点读取或接收扭矩、角度等时序数据。
- 对多个时序序列做基础对齐、清洗和截取。
其中一个常见处理是以扭矩达到某个阈值的位置作为切分点，只保留有效工艺区间。
2. 曲线对齐
曲线对齐是曲线分析里最关键的预处理之一。
系统会根据不同场景选择不同的对齐基准，例如：
- 起点对齐。
- 终点对齐。
- 结果角度对齐。
- 最大角度对齐。
实现上，对齐本质上是在时间轴或角度轴上选定一个基准点，然后把原始序列转换成相对序列，便于后续比较和建模。
3. 特征计算
特征计算关注的是“从曲线里抽取什么数值”。
常见特征包括：
- 最大值。
- 最小值。
- 均值。
- 峰值位置。
- 斜率变化。
- 平台段长度。
特征策略通常返回的是一个中间结果集合，供后续策略判定或趋势分析使用，不直接负责最终规则结论。
4. 模型推理
模型推理包含机器学习模型和神经网络模型两类。
机器学习模型的输入通常是曲线序列本身，或经过轻度处理后的序列。输出一般是异常分值、重建损失、梯度损失、加速度损失或其他模型内部评分。
神经网络模型通常通过模型平台接入，技术上更偏“外部推理服务调用”。系统侧只关心统一的调用协议和结果解析，不关心模型内部结构。
5. 策略执行
策略是统一的执行壳，负责把不同类型模型的输入、调用和结果标准化。
一个策略执行通常包含：
- 组织输入数据。
- 调用对应模型或特征算法。
- 解析模型返回值。
- 构造单个策略运行结果。
策略的作用是把模型能力变成可执行、可存储、可回放的单维度判定结果。到这里为止，边缘端已经完成“从曲线计算到策略结果”的闭环，但还没有生成最终事件。
云端规则判定链路
云端规则判定链路的目标，是从已经同步上来的策略结果中筛选适用规则，并决定是否生成事件。
规则层不做模型推理，只做策略结果编排、规则表达式判定和事件触发。
flowchart TD
A["接收一条曲线的策略运行结果"] --> B["筛选 scope 候选规则"]
B --> C["统计实际运行的策略结果分类"]
C --> D["只保留与结果类型一致的规则"]
D --> E{"存在对应类型规则？"}
E -->|否| F["跳过事件判定<br/>该曲线不需要生成事件"]
E -->|是| G["执行 direct 或 combination 判定"]
G --> H{"最终结果是否 NOK？"}
H -->|否| I["写入 OK / 非事件结果"]
H -->|是| J["生成事件"]
1. 作用域筛选
规则筛选先根据设备和分类号确定候选规则。筛选顺序是从最具体到最通用：
- 优先匹配“设备 + 分类号”规则。
- 未匹配到时，再匹配设备级规则。
- 仍未匹配到时，使用未设置 scope 的基础规则。
同一作用域下可能得到多个不同类型的规则，因此作用域筛选只解决“哪些规则可能适用于这条曲线”，不直接决定最终使用哪一条规则。
2. 策略运行结果分类
规则判定只统计实际运行的策略。没有运行的策略不进入分母，也不影响最终结果分类。
如果实际运行数为 0，说明当前曲线没有可用于规则判定的策略结果，应直接跳过规则判定。
策略运行结果分为四类，且四类互斥：
| 分类 | 判定条件 | 含义 |
|---|---|---|
| 全部通过 | passed == total |
实际运行的策略全部通过。 |
| 全部不通过 | passed == 0 |
实际运行的策略全部不通过。 |
| 绝大多数通过 | passed * 2 >= total |
通过数不少于运行数的一半。 |
| 部分通过 | 0 < passed * 2 < total |
有策略通过，但通过数少于运行数的一半。 |
判定顺序必须先判断“全部通过”和“全部不通过”，再判断“绝大多数通过”和“部分通过”，避免全部通过被多数通过包含。
奇数数量不要使用四舍五入或整数除法近似，应使用精确比较。例如用 passed * 2 >= total 表达“通过数不少于一半”。
3. 规则筛选与判定
得到 scope 候选规则和策略运行结果分类后，再做规则类型筛选：
- 从 scope 候选规则中，只保留与策略结果类型一致的规则。
- 找不到对应类型规则，说明该曲线不需要事件判定，直接跳过。
- 找到对应类型规则后，再执行规则的
direct或combination判定。
direct 规则适合对单个策略结果、单个判定因子或单个分类结果做直接判断。
combination 规则适合对多个策略结果进行组合判断，例如与、或、优先级、阈值组合和多条件编排。
4. 事件生成
规则判定结果不等于策略运行结果。策略运行结果只是规则判定的输入，最终事件是否生成由云端规则判定结果决定。
- 最终结果为
NOK：生成事件。 - 最终结果为
OK：只记录结果，不生成事件。 - 没有匹配到对应类型规则：跳过事件判定，不生成事件。
因此，规则链路的核心原则是：只有云端规则判定为 NOK，才生成事件。
异步机制
系统里最重要的异步机制有三种。
1. 队列驱动
曲线计算、标准曲线训练、结果同步等长耗时任务，可以通过消息队列触发。
好处是：
- 解耦请求与计算。
- 方便削峰。
- 便于失败重试和补算。
2. 线程池并发
曲线查询、曲线构造和训练任务都可能使用线程池并发拉取时序数据，避免单点串行等待。
这类并发适合“多个曲线、多个采集项”的独立查询场景。
3. 结果回写
边缘端计算完成后，策略结果会同步回云端结果中心；云端规则判定完成后，规则结论和事件结果会继续写入结果中心或事件中心。
这种“算完再回写、判完再生成”的方式，保证了查询侧、计算侧和规则侧解耦，也方便后续追溯和重放。
主要存储与中间产物
实现上通常会保存四类产物：
| 产物类型 | 主要位置 | 内容 |
|---|---|---|
| 配置产物 | 云端配置中心，下发到边缘端 | 模型、策略、规则、参考曲线、scope。 |
| 训练产物 | 云端或模型平台，必要时同步边缘端 | 训练结果、阈值、模型标识、参考曲线产物。 |
| 计算产物 | 边缘端生成，云端结果中心留痕 | 策略结果、判定因子、曲线摘要。 |
| 判定与反馈产物 | 云端生成 | 规则判定结果、事件记录、回写给现场或第三方系统的数据包。 |
技术上，系统的关键不是某一种数据库，而是这些产物在边缘端和云端之间如何保持一致性和可追溯性。
技术边界
这套实现的技术边界可以概括为：
- 负责曲线质量分析，不负责通用数据分析平台。
- 负责曲线、模型、策略和规则的闭环，不负责底层采集硬件本身。
- 负责边缘端策略计算和云端规则判定，不把事件规则下沉为现场控制逻辑。
- 负责结果生成、事件生成和同步，不直接替代现场 PLC 或设备控制策略。
作为系统构建输入时的价值
这份技术笔记适合在系统构建前提供以下输入：
- 系统该分哪些层。
- 数据、计算、规则和事件分别位于哪里。
- 哪些任务需要异步化。
- 哪些能力属于模型，哪些能力属于策略，哪些能力属于规则。
- 结果应该如何从曲线数据逐级收敛到策略结果、规则结论和事件。
它不替代详细设计，但足以帮助团队建立统一的技术实现视角。